-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docker - failed to open stream permission denied #58
Comments
I am having this issue too. Any ideas on how to fix this? |
This issue is caused by different user ids on the host and in the container. Some user manipulation at the command line might work. A quick work around is to create an empty output file, set the permissions to match the user in the container and then force-write the generated image over the dummy image.
docker run --rm -it --name dcv pmsipilot/docker-compose-viz id
uid=1000(dcv) gid=1000(dcv) groups=1000(dcv)
sudo chown 1000:1000 docker-compose.png
docker run --rm -it --name dcv -v $(pwd):/input pmsipilot/docker-compose-viz render -m image --force docker-compose.yml |
I fixed this by just giving write permissions to the entire project folder |
another workaround that is a bit cleaner IMHO: run the container with the docker run --rm -it --user $UID:$GID --name dcv -v "$(pwd):/input" pmsipilot/docker-compose-viz render -m image docker-compose.yml |
it's because your dir is not writeable by
|
This is crucial. And therefore rather unusable. It merely helps with diagnosing, but there are far better ways to do this - higher in the thread there's commands running "Temporarily" means that you must run it right before each time of running the docker and then reverting right after - but there's no example on how to revert. Leaving it chmod 777 not only is a security issue, it can and will cause docker to write files that will break backups, that make moving and even searching this dir hard or impossible. It's, overall, bad advise. TL;DR: don't use this chmod 777. |
This repo is already allowing inevitable access to host from container by such a design. I'd rather create an empty and harmless testing directory with permissive permissions just for retrieving the visualization image and tear it down after use. 777 is there for a reason if you know to use it to make your work convenient without security tradeoff. Now it's weird if you plan to put your critical files in there. edited: out -> put |
The main issue is that files inside this dir are not owned by you, but by root. You cannot move, backup, cleanup or archive your project without root. Search, grep, and anything that hits this file will flunk or even break. There are several options proposed in this exact thread which work fine and have non of these downsides. "Chmod 777" to solve docker issues is almost never the right solution. One more, that doesn't involve chmodding nor any other commands, is to output to /tmp/ (tmp is designed to be writable and readable by all users)
|
I tried docker-compose-viz
The text was updated successfully, but these errors were encountered: