Cypress: Cypress should not require write access of root folder
Why do we check if the root of the project is writeable? 👇 i.e. the fs.accessAsync(projectRoot, fs.W_OK)
cc:/ @zacblazic
itskingori
All 43 comments
Because we seed the project with cypress.json and the cypress folder and example spec code, and plugins, and fixtures, etc.
brian-mann
on 8 Feb 2018
@brian-mann Right. We're using this in Docker and common practice is to run the app as non-root. This means that we'd have to give the user access to write to the root of the app which is unnecessary since our app already has cypress.json and cypress/. Just giving you more context.
That said, seeding the project happens once and probably locally, right? Is this check really necessary?
itskingori
on 8 Feb 2018
I see - with that said, we should only do this check if we believe we need to seed something in the root folder.
brian-mann
on 8 Feb 2018
Yes. And this is why when the official Docker image set the user to a non-root user, many people were simply unable to work with it because of permission denied errors. See https://github.com/cypress-io/cypress-docker-images/issues/10. The solution then was just to use root and let user's do whatever they want on their own images.
Just wanted to check with you guys if you're aware of this use case and the implications of this part of the code to that use case.
That said, I think my work is done. I'm not sure if I should keep this open or not. 🤔
itskingori
on 8 Feb 2018
I agree with your suggestion and we'll get this out in a patch release.
brian-mann
on 13 May 2018
I am currently experiencing the same issue while running it on Bitrise. Is there an expected timeline as to when this will get completed? If there is a working solution already I'd love to take a look at it.
Bhavik-P
on 1 Jun 2018
@Bhavik-P @itskingori we talked about this at our team meeting today.
Even though we may not need to check for write access permissions to the project root - we still need write permissions to folders like cypress/videos or cypress/screenshots and the consensus was that these permissions would not be different than the projectRoot.
Can you two confirm or explain how this would NOT be the case? In other words, while we could remove this one specific check here, we'd have to add at least 2 more checks in other folders that are nested inside of the projectRoot. If the entire subtree has the same permissions it would simply error later in the process as opposed to here.
brian-mann
on 25 Jun 2018
@brian-mann CI tools don't usually allow root access to apps. When I try to install Cypress locally (instead of globally) it doesn't pose any issues because the user has write-access to all subdirectories. The issue with this is that when I run the Cypress command, it says command not found. I have installed other libraries globally on Bitrise. Can you recommend something else that I can try? What if I don't want to use screenshots and videos?
Bhavik-P
on 25 Jun 2018
Wait, you are installing Cypress globally as in “npm i -g cypress”?
Sent from my iPhone
On Jun 25, 2018, at 14:29, Bhavik Patel notifications@github.com wrote:
@brian-mann CI tools don't usually allow root access to apps. When I try to install Cypress locally (instead of globally) it doesn't pose any issues because the user has write-access to all subdirectories. The issue with this is that when I run the Cypress command, it says command not found. I have installed other libraries globally on Bitrise. Can you recommend something else that I can try? What if I don't want to use screenshots and videos?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
bahmutov
on 25 Jun 2018
Yes; installing it using npm install --save-dev cypress leads to a bash error command not found
Bhavik-P
on 25 Jun 2018
@Bhavik-P to get on the same page I think we need to define terms a bit better.
You say: root access to apps but this makes no sense to me. Cypress does not require root access - it requires write access to the project's root directory. This is simply the folder that contains cypress.json. It would be the same folder that's created with the git clone command.
We only write inside of that project folder. This is the same level of access that any node_module would need when running npm install.
In fact... how does your project ever run npm install? That needs the same level of write access as Cypress does to node_modules.
brian-mann
on 25 Jun 2018
@brian-mann
I was trying to install the package globally instead of with the project directory. When doing so, it required root access to write folders which for obvious reasons cannot be permitted. When I installed it in the project directory, I was able to install it, however, I couldn't just make a call to Cypress (cypress run) as I would when I globally installed it. This is where I went wrong. I knew something had to be wrong on my end so I looked at the docs and realized I missed a very important step. I needed to run cypress as such: $(npm bin)/cypress. I appreciate your time and thanks for the quick responses.
Bhavik-P
on 26 Jun 2018
@itskingori do you mind weighing in on my comment here: https://github.com/cypress-io/cypress/issues/1281#issuecomment-400075705
We decided to fix this issue but once we investigated it, it made no sense how or why this would solve anything.
We'd really like to understand how Cypress doesn't have write access to the project root (where cypress.json is stored) and yet node_modules would have write access to the same exact folder?
brian-mann
on 28 Jun 2018
Just have a similar problem, just worse: Cypress tries to create a directory below the system root, not just the project root, like /.Trash-1002, which I suspect might be related.
fgm
on 28 Jun 2018
Here is Cypress attempting to gain access to root of a docker image where our install is happening. Please note that this isn't even us running cypress. The project is simply running it's normal build process but this time we have added cypress to the project and during a yarn/npm install cypress attempts to access root to make a /.cache/Cypress directory. It seems like an install script that cypress attempts to run regardless of whether it's CI or not and in our jenkins pipeline it will fail as these are being built on docker images. Our options then are either to disable all scripts which could be detrimental with other dependencies, or to remove Cypress completely from the project... which we would rather not do... just yet...
```shell
error An unexpected error occurred: "/tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2/node_modules/cypress: Command failed.
Exit code: 1
Command: sh
Arguments: -c node index.js --exec install
Directory: /tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2/node_modules/cypress
Output:
Cypress cannot write to the cache directory due to file permissions
Failed to access /.cache/Cypress:
EACCES: permission denied, mkdir '/.cache/Cypress'
Platform: linux (Debian - 8.10)
Cypress Version: 3.0.2".
info If you think this is a bug, please open a bug report with the information provided in "/tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
error An unexpected error occurred: "Command failed.
Exit code: 1
Command: sh
Arguments: -c yarn install --frozen-lockfile
Directory: /tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2
Output:
".
info If you think this is a bug, please open a bug report with the information provided in "/tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error An unexpected error occurred: "Command failed.
Exit code: 1
Command: sh
Arguments: -c yarn log:sha && yarn i
Directory: /tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2
Output:
".
info If you think this is a bug, please open a bug report with the information provided in "/tmp/jenkins-1112/workspace/xxxxxxx-7-4-TK7RUNRBZAPATDAVC@2/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
script returned exit code 1```
DavideDaniel
on 5 Jul 2018
Here's Angular's use case: for performance, we are rolling out a remote execution system where a farm of machines can run build/test actions.
When a test runs remotely, we copy over the declared inputs, run the test executor, then collect the outputs written to specified locations back to your machine. The remote execution uses a containerized FS where we prevent writes to the project directory, as these would be lost and not copied back to your machine.
I would like to run Cypress on such a remote build/test farm, which requires that we be able to configure the locations where it writes files, and it shouldn't check for write access in other locations.
alexeagle
on 6 Jul 2018
@DavideDaniel per our installation docs we are pretty clear that Cypress will cache itself in the system cache folder appropriate for each operating system. In linux it would be /.cache - many other modules do this as well. This is very common, even moreso common for modules to store global configuration in places like /.config.
At any rate - per our installation docs you can with a simple environment variable change the location of this cache yourself here: https://docs.cypress.io/guides/getting-started/installing-cypress.html#Advanced
You can either skip the binary installation (if you have it cached elsewhere) or control where you want it to be installed.
What do you do about caching other things like your node_modules? Whatever mechanism you use for those you could use for Cypress which would prevent it from even needing to install when Jenkins loads.
brian-mann
on 7 Jul 2018
@fgm see my comment here: likely this is the same issue with caching https://github.com/cypress-io/cypress/issues/1281#issuecomment-403233215
brian-mann
on 7 Jul 2018
@alexeagle can you explain how if you want to disable write access to the project - Cypress would be able to generate any assets from the run? Things like logs, screenshots, videos, etc?
Can you suggest to us what you'd like Cypress to do instead?
Currently you can turn off taking screenshots and video in the configuration. Although we do have a hardcoded check to ensure the project root has write access. We can remove that check (or turn it into a warning) if need be. But I still don't understand how this really achieves anything considering you won't be able to capture anything from the test runs.
brian-mann
on 7 Jul 2018
I assume that stdout is used for the primary pass/fail UI. I'd like to
configure a directory where those additional files are written.
On Sat, Jul 7, 2018, 11:04 AM Brian Mann notifications@github.com wrote:
@alexeagle https://github.com/alexeagle can you explain how if you want
to disable write access to the project - Cypress would be able to generate
any assets from the run? Things like logs, screenshots, videos, etc?Can you suggest to us what you'd like Cypress to do instead?
Currently you can turn off taking screenshots and video in the
configuration. Although we do have a hardcoded check to ensure the project
root has write access. We can remove that check (or turn it into a warning)
if need be. But I still don't understand how this really achieves anything
considering you won't be able to capture anything from the test runs.—
You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub
https://github.com/cypress-io/cypress/issues/1281#issuecomment-403233375,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC5Iyk2aeqdeEegx3ZQFLWxHdGVNc8Uks5uEPg3gaJpZM4R-hlS
.
alexeagle
on 7 Jul 2018
@brian-mann thanks for the answer /.cache is rather uncommon AFAIK and not compliant with the linux Filesystem Hierarchy Standard. Per-user caches should go into ~/.cache, so typically in /root/.cache for caches for the root user ; while global runtime cache like these should probably go in /var/cache (/run/cache in the upcoming version of the FHS).
fgm
on 9 Jul 2018
@fgm sorry I did not explain correctly - it DOES go into the user's ~/.cache directory. We use this module here to create the paths: https://github.com/LinusU/node-cachedir
You can see that's where it puts it. I guess I'm now confused what the actual problem is now since this is the correct and intended behavior of how it installs.
@alexeagle You can already do exactly just that - Cypress provides options via its cypress.json to configure exactly where you want those folders to go. You can even override those values with environment variables specifically for CI.
brian-mann
on 9 Jul 2018
@brian-mann : the problem I have is that it tries to write in /, to create directory/.Trash-1002, not in ~ like /root/.Trash-1002, which would be writable.
fgm
on 9 Jul 2018
When does it try to do this? This should not happen.
Sent from my iPhone
On Jul 9, 2018, at 21:38, Frédéric G. MARAND notifications@github.com wrote:
@brian-mann : the problem I have is that it tries to write in /, to create directory/.Trash-1002, not in ~ like /root/.Trash-1002, which would be writable.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
bahmutov
on 9 Jul 2018
@brian-mann So if we disabled video / screenshot generation.
And you disable the hard coded write access check (replace with warning)
Then there shouldn't be anything stopped us from using Cypress in a containerized read only FS, correct?
Toxicable
on 10 Jul 2018
:( Could you please remove the FS write check, this is also blocking us.
publicvirtualvoid
on 12 Jul 2018
@brian-mann ty for the tip about the advanced installation. Adding an env var for caching the binary pointed somewhere within the working directory path helped.
For anyone else with a similar error to the one I mentioned, using CYPRESS_CACHE_FOLDER as referenced in https://on.cypress.io/installing-cypress#Overriding-the-Binary-Cache-Folder might help.
DavideDaniel
on 13 Jul 2018
Whats the resolution here? Are we getting the FS check removed? (or replaced with a warning)
Toxicable
on 16 Aug 2018
@bahmutov this happens beffore the (Run Starting) message
npx cypress run -s .cypress/integration/meteor_spec.js
Warning: We failed to trash the existing run results.
This error will not alter the exit code.
Error: EACCES: permission denied, mkdir '/.Trash-1002'
====================================================================================================
(Run Starting)
┌────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Cypress: 3.0.3 │
│ Browser: Electron 59 (headless) │
│ Specs: 1 found (meteor_spec.js) │
│ Searched: .cypress/integration/meteor_spec.js │
└────────────────────────────────────────────────────────────────────────────────────────────────┘
Any update on this? Would be great for the check to be removed for the read only FS use case. And Videos/Screenshots will be written into a custom writable location.
Globegitter
on 23 Oct 2018
Could we get some movement here? It's a pretty easy code change from the looks of it.
Toxicable
on 9 Mar 2019
FYI this may become a blocker for using Cypress under Angular CLI at some point, when we use a buildtool that creates a readonlyFS for hermeticity during testing
alexeagle
on 12 Mar 2019
Short answer: just delete the video folder and run cypress again.
Long answer: i have cypress dockerized within my project,
so whenever i run cypress from docker it creates video and screenshot folders inside my project.
The problem for me was when i installed cypress globaly and wanted to run cypress locally, without docker, i was getting the required write access problem, but deleting the folders created by the dockerized version solved everything.
Spartano
on 4 Jun 2019
@jennifer-shehane Is there anything that can be done to push forward this proposal?
Toxicable
on 12 Aug 2019
https://github.com/cypress-io/cypress/issues/2821#issuecomment-444109124
This fixed my issues running Cypress in Jenkins using the official docker image
thomaswelton
on 10 Sep 2019
@Toxicable We are open to PR requests from anyone. Read our contributing guides to get started.
jennifer-shehane
on 28 Oct 2019
@jennifer-shehane link points to a dead location. Could you update please.
RobDBob
on 21 Nov 2019
How can I add Cypress in Bitbucket pipeline?
Im getting this error in pipeline
+ DISABLE_OPENCOLLECTIVE=true npm install
> [email protected] postinstall /opt/atlassian/pipelines/agent/build/node_modules/cypress
> node index.js --exec install
Cypress cannot write to the cache directory due to file permissions
See discussion and possible solutions at
https://github.com/cypress-io/cypress/issues/1281
----------
Failed to access /root/.cache/Cypress:
EACCES: permission denied, mkdir '/root/.cache/Cypress'
----------
Platform: linux (Raspbian - )
Cypress Version: 3.8.2
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/jest-haste-map/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] postinstall: `node index.js --exec install`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] postinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2020-01-15T14_58_55_234Z-debug.log
codler
on 15 Jan 2020
npm install --unsafe-perm solved it for me
codler
on 16 Jan 2020
I am also having permissions issue but creating a lock file inside /tmp/cypress. Since the machine can be used by multiple users in our case, if one user ran tests, other user can't coz of loosing control of /tmp/cypress. I am getting following error.
[OperationalError: EACCES: permission denied, open '/tmp/cypress/4fa88ed0720f436f49e09ac33f63413a.lock'
] { cause: [Error: EACCES: permission denied, open '/tmp/cypress/4fa88ed0720f436f49e09ac33f63413a.lock' ] {
errno: -13,
code: 'EACCES',
syscall: 'open',
path: '/tmp/cypress/4fa88ed0720f436f49e09ac33f63413a.lock'
},
isOperational: true,
errno: -13,
code: 'EACCES',
syscall: 'open',
path: '/tmp/cypress/4fa88ed0720f436f49e09ac33f63413a.lock'
}
Error: EACCES: permission denied, open '/tmp/cypress/4fa88ed0720f436f49e09ac33f63413a.lock'
Tried different ways mentioned above but didn't solve the issue.
thecodejack
on 10 May 2020
An option to turn off the write check would be useful. The problem most of have is likely a lack of dev-ops and linux permission experience, however if we are just running tests and writing to stdout, dropping the write access might make adopting Cypress easier for many people.
lmiller1990
on 10 May 2020
The code for this is done in cypress-io/cypress#7126, but has yet to be released.
We'll update this issue and reference the changelog when it's released.
![cypress-bot[bot] picture](https://avatars3.githubusercontent.com/u/8908513?v=4&s=40)
cypress-bot[bot]
on 12 May 2020
Released in 4.6.0.
This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v4.6.0, please open a new issue.
cypress-bot[bot]
on 20 May 2020
Related issues
brian-mann
·
3Comments
simonhaenisch
·
3Comments
egucciar
·
3Comments
weskor
·
3Comments
igorpavlov
·
3Comments
Most helpful comment
npm install --unsafe-permsolved it for me