I have a similar problem to that posted here, in that a user is unable to access the contents of a directory they own. A quick search shows quite a few other similar questions, however the problem always seems to be the execute bit not being set on a directory. Perhaps I've missed something for having stared at this one for so long, but that doesn't seem to be my problem.
As with the other questions, it is probably easier to show:
me@docker-host:~$ docker exec -it sp-rsync-1 bash
root@sp-rsync-syn-send:/# su --login sync_user
sync_user@sp-rsync-syn-send:~$ ls -al
total 24
drwxr-xr-x 6 sync_user sync_user 4096 Feb 9 20:24 .
drwxr-xr-x 6 root root 4096 Feb 9 20:24 ..
-rw-r--r-- 1 sync_user sync_user 220 Apr 9 2014 .bash_logout
-rw-r--r-- 1 sync_user sync_user 3637 Apr 9 2014 .bashrc
-rw-r--r-- 1 sync_user sync_user 675 Apr 9 2014 .profile
drwx------ 2 sync_user sync_user 4096 Feb 9 20:24 .ssh
As you can see, the .ssh directory is owned by sync_user with 0700 permissions. However:
sync_user@sp-rsync-syn-send:~$ ls -al .ssh/
ls: cannot open directory .ssh/: Permission denied
But it does appear that the user owns the directory:
sync_user@sp-rsync-syn-send:~$ chmod 0777 .ssh
sync_user@sp-rsync-syn-send:~$ ls -al
total 28
drwxr-xr-x 7 sync_user sync_user 4096 Feb 9 21:23 .
drwxr-xr-x 7 root root 4096 Feb 9 21:05 ..
-rw------- 1 sync_user sync_user 58 Feb 9 21:05 .bash_history
-rw-r--r-- 1 sync_user sync_user 220 Apr 9 2014 .bash_logout
-rw-r--r-- 1 sync_user sync_user 3637 Apr 9 2014 .bashrc
-rw-r--r-- 1 sync_user sync_user 675 Apr 9 2014 .profile
drwxrwxrwx 2 sync_user sync_user 4096 Feb 9 20:24 .ssh
Not that it helps:
sync_user@sp-rsync-syn-send:~$ ls -al .ssh/
ls: cannot open directory .ssh/: Permission denied
For a little more information:
sync_user@sp-rsync-syn-send:~$ ls -ain
total 24
885 drwxr-xr-x 6 1200 1200 4096 Feb 9 20:24 .
852 drwxr-xr-x 6 0 0 4096 Feb 9 20:24 ..
905 -rw-r--r-- 1 1200 1200 220 Apr 9 2014 .bash_logout
890 -rw-r--r-- 1 1200 1200 3637 Apr 9 2014 .bashrc
889 -rw-r--r-- 1 1200 1200 675 Apr 9 2014 .profile
904 drwx------ 2 1200 1200 4096 Feb 9 20:24 .ssh
sync_user@sp-rsync-syn-send:~$ id sync_user
uid=1200(sync_user) gid=1200(sync_user) groups=1200(sync_user)
Dropping back to root and listing the directories permissions:
root@sp-rsync-syn-send:/# ls -ail /home/sync_user/.ssh/
total 16
904 drwx------ 2 sync_user sync_user 4096 Feb 9 20:24 .
885 drwxr-xr-x 6 sync_user sync_user 4096 Feb 9 21:05 ..
917 -rw------- 1 sync_user sync_user 394 Feb 9 18:51 authorized_keys
916 -rw------- 1 sync_user sync_user 1679 Feb 9 18:51 id_rsa
Also The permissions on the /homeand / are 0755 with root as owner and group.
root@sp-rsync-syn-send:/# ls -al /home
total 12
drwxr-xr-x 7 root root 4096 Feb 9 21:05 .
drwxr-xr-x 88 root root 4096 Feb 9 21:17 ..
For further background, the user has been created within a docker container as part of the build process, therefore my suspicions are that this is either something to do with how I am su'ing to this user (hence explicitly using su --login, or that this could be a problem with the AUFS filesystem.
Update
Just to prove I'm in the right place:
sync_user@sp-rsync-syn-send:~$ pwd
/home/sync_user
Update 19th Feb 2016
I don't believe it counts as a solution, since I side stepped the original issue, so I'm not going to post is as an answer. For me, I stopped explicitly creating the .ssh directory using a mkdir comment and instead set up the creation of the .ssh by placing it into /etc/skel.
Richard points out in the comments below that there is a Docker bug with the AUFS file system that I think is well the cause of this issue; unfortunately I don't have time to further look into it as the actual cause or whether there is a solution.
Potentially some relevant facts for anyone else stumbling on this issue: Docker version: 1.9.1
