-
Notifications
You must be signed in to change notification settings - Fork 18.7k
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
permission denied if chown after chmod #6047
Comments
edit: disregard my issue, Docker compiled from master works fine so I think this issue has already been fixed
|
Nevermind! I just compiled Docker from master and it works fine. I'll be eagerly awaiting Docker 0.11.2 😄
|
This issue still exists in Docker 1.0.1
This fails:
While swapping
|
I'm seeing a similar issue with my Dockerfile at However, when I build the same Dockerfile using boot2docker on OS X, the permissions are preserved
|
Using Docker 1.1.1 and Docker built from master, I couldn't reproduce the bug with two Dockerfiles:
I couldn't reproduce this on AUFS, devicemapper and btrfs. This looks like an environment problem (kernel, fs or other configuration problem). Can anyone who's running into this provide the full output of |
For last case (larry), I still met the problem
And related conf
Later me know if need more information |
same on Ubuntu 14.04 VM in Windows
fs type for |
The machine giving me errors:
The machine I built the image on:
The errors (and mixed file ownership?!) I see:
Dockerfile commands:
I commented out the
EDIT: I added some Dockerfile steps above that I had accidentally cut out the first time around. |
I should add that I don't have any permission problems when running a container from this image on the build machine (using devicemapper-thin), only on the cloud VM (which uses aufs). I dumped the directory listings for each relevant branch of the aufs graph -- it's pretty verbose so I'm putting it in this gist : https://gist.github.com/jdef/bdab1acec40338e6ddc1 |
@jdef What is the |
@abevoelker , the only thing I'm mounting is a syslog UNIX domain socket, and that doesn't change the outcome.
|
Looks like aufs3 supports a |
Was looking at this one, and to add to the weirdness, the following Dockerfile shows that there's a difference when the chmod and chown are on the same line vs on different lines - this could be an indication of it being a aufs issue: FROM ubuntu In the above Dockerfile, the "good" path works just fine, but the "bad" gets an error: |
I have Docker on three different host machines, two exhibit this problem and one doesn't. Config details of all three: http://pastebin.com/zUqnJrDj The issue I'm facing is not just that I can't change the permissions; it seems like I "can" change the permissions, but the change has no effect (silent fail). I've been trying to build an image based on my work in progress here: https://github.com/fazy/docker-apache-symfony/tree/permissions-issue/web When running, Apache is giving "403 Forbidden" because it can't access the directory to check for a .htaccess file. If I create the right permissions before running Files used to build the container: Contents of the working directory within my context when building:
After building I run like this:
Requests for Files inside the container: Here's what I see when I
Then I try to change the permissions and view again:
It looks like everything is correct now; but I still get the 403 forbidden error. Obviously I wouldn't normally go in with nsenter, but do it in This in Dockerfile didn't work (same behaviour as above):
The Dockerfile ends with:
Adding that chmod command to The only way I've managed it is using a temp directory:
Aside from performance costs with a real world app, I'm a bit worried about the fact that this behaviour is easy to overlook (maybe sometimes when I ADD the files the permissions are already correct, but then another time they're not). Because this limitation is so counter-intuitive, can there be a big, bold warning at the top of this section please? http://docs.docker.com/reference/builder/#add Also, I note the discussion in #783. If I understand correctly it seems Docker is moving towards DeviceMapper, but AUFS is still the default when present. I'm not sure why two of my Debian-based systems have AUFS. One of them is running inside VMWare on Windows, and the other is installed directly on an Intel-based PC. Maybe more should be communicated about the choice of filesystems? I can't see any mention of DeviceMapper in the Ubuntu or Debian install guides for example. For now, I will try and move over to DeviceMapper (this article looks like a good starting point). |
Same problem. Swapping the chmod/chown statements seems to work fine. Ubuntu 14.04.1 LTS Client version: 1.3.2 |
i presume this is the aufs issue? |
@ricardobranco777 , problem exist still in Docker 1.4.1, Verified in boot2docker 1.4.1. aufs problem. |
@ricardobranco777 using which graphdrivers ( |
I can also confirm this is still happening |
Certainly only with aufs. The main problem with this is with file build complexity. If a dockerfile up the chain does a chmod (or say an package install command does) you cannot fix the permissions on the file/folder by any means (minus a move and move back as root which works). In addition even without a chroot involved a chmod after chmod does not work (so chmod a folder 700 then back to 755 and no one but root can ls it). Below are two examples, a very simple one of the original problem and a second one showing all the oddities (for example if the folder was chmodded 711 then a chown is done the user can write to the folder they own but not list the contents).
docker build -t test . && docker run -t -i test
Now to show the real craziness:
docker build -t test . && docker run -t -i test
As mentioned a simple move and move back however works, take the first example and add one line to the docker file:
and now it works just fine. |
@mitchcapper can you please try with the latest version of docker |
could this be related to #783 |
it seems to have the same comments and problems as #783 https://docs.docker.com/release-notes/#known-issues |
@jfrazelle yes it still occurs. I assume once #10390 gets merged in and the dirperm1 opt is available it will go away. Is there a reason this is thought to be fixed otherwise? |
This is still an issue on v1.12.1 with ubuntu 16.04 as both host and container. chmod THEN chown:
chown THEN chmod:
|
@tomaspinho possibly an issue in the aufs kernel module; see #20240 (comment), and #24660 |
@thaJeztah thanks, but it's easier to just change the Dockerfile, as monkeypatching kernel modules is not an option in my environment. Just left this as docs for other people that may be facing the same |
This runs, it gives a 0 Exit status:
However if I simply change the chown command to be just after the chmod commands like this:
then running it fails with:
I have confirmed the this with several other things too, for example changing the command like so:
as well as just running bash interactively and manually attempting to touch/list the files that were chown-ed.
It also does not seem to be related to bash or the environment (that I know of,) since I discovered this issue while doing this:
which produced the sshd debug error:
and all it took for it to start working was to move the chown command above the chmod commands.
Is this a bug or am I missing something here? Thanks all.
UPDATE: with my host info:
Ubuntu 12.04
The text was updated successfully, but these errors were encountered: