I have been able to install and run NextJS in Elastic Beanstalk previously, but now I get the following error; I do have a .npmrc with unsafe-perm=true in though so I should be installing as root - is the file present that it says it cannot access?
> Build error occurred
{ Error: EACCES: permission denied, open '/tmp/.config/nextjs-nodejs/config.json'
at Object.openSync (fs.js:443:3)
at Object.readFileSync (fs.js:343:35)
at Conf.get store [as store] (/var/app/current/node_modules/conf/index.js:228:18)
at new Conf (/var/app/current/node_modules/conf/index.js:92:26)
at new Telemetry (/var/app/current/node_modules/next/dist/telemetry/storage.js:22:424)
at build (/var/app/current/node_modules/next/dist/build/index.js:3:323)
errno: -13,
syscall: 'open',
code: 'EACCES',
path: '/tmp/.config/nextjs-nodejs/config.json' }
The next 9.1.2 package should install like 9.1.1 does.
The deployment should work, as it does with 9.1.1
Please follow the issue template.
https://github.com/zeit/next.js/issues/new/choose
https://github.com/zeit/next.js/issues/new?template=8.Question_about_next.md
# Question about Next.js
GitHub Issues are reserved for Bug reports and Feature requests. The best place to get your question answered is to post it on https://spectrum.chat/next-js.
This is clearly a bug introduced in version 9.1.2
Didn't spend too much time on it. However revert back to 9.1.1 is a workaround.
Didn't expect the minor version upgrade break the deployment as a mature product
@timneutkens @eNkru I have amended it so it follows the bug report template, but as eNkru confirms above this is an issue in the package; not my usage as rolling back the package fixes the issue. This is a fault in 9.1.2.
The next 9.1.2 package should install like 9.1.1 does.
This is not a clear and concise reproduction. Which makes it extremely hard to look into the particular issue that you're having.
It basically leaves us "guessing" what's wrong in your specific case and we won't be able to add tests for that case to avoid breaking it in the future.
I'll re-open but this is not actionable from our side without a reproduction as I'm sure you can understand.
Didn't expect the minor version upgrade break the deployment as a mature product
We have tests for all features covering everything from development hot module replacement to production builds in every possible setting you can think of.
You're the first to report this so it's very likely an edge case on a very small number of users' deployment environment.
We are also seeing this issue trying to deploy to EBS.
> NODE_ENV=production next build
Creating an optimized production build...
> Build error occurred
{ Error: EACCES: permission denied, open '/tmp/.config/nextjs-nodejs/config.json'
at Object.openSync (fs.js:436:3)
at Object.readFileSync (fs.js:341:35)
at Conf.get store [as store] (/var/app/current/node_modules/conf/index.js:228:18)
at new Conf (/var/app/current/node_modules/conf/index.js:92:26)
at new Telemetry (/var/app/current/node_modules/next/dist/telemetry/storage.js:22:424)
at build (/var/app/current/node_modules/next/dist/build/index.js:3:323)
errno: -13,
syscall: 'open',
code: 'EACCES',
path: '/tmp/.config/nextjs-nodejs/config.json' }
npm ERR! code ELIFECYCLE
As a fix for now I was able to get it working by adding the following to .ebextensions/00_permissions.config
files:
"/opt/elasticbeanstalk/hooks/appdeploy/post/00_permissions.sh":
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
chown -R nodejs:nodejs /tmp/.npm
chown -R nodejs:nodejs /tmp/.config
Also running into this issue...
Same issue here
Same here !
A solution has already been posted:
https://github.com/zeit/next.js/issues/9294#issuecomment-549541606
Requiring root to install doesn鈥檛 really feel solution, it feels like a workaround the actual problem - something changed in the version release.
A solution has already been posted:
#9294 (comment)
Still experiencing the same issue even after adding a .ebextensions/00_permissions.config
This is clearly a bug introduced in version 9.1.2
Didn't spend too much time on it. However revert back to 9.1.1 is a workaround.
Didn't expect the minor version upgrade break the deployment as a mature product
Work well in 9.1.1, still a bug in 9.1.4