idmapping new files always nobody
johnlane opened this issue · 4 comments
Hello, I have set up krb5 kerberised nfsv4 with id mapping. It would appear to work as expected except that files created on the client are owned by nobody.
I have directory on the server, from the export point downwards it's owned by a user, say foo with uid and gid 2000. I have an attached client that has the export mounted and all the files appear within owned by foo (but the local uid/gid is 1000).
The directory appears on the client
drwxr-xr-x 2 foo foo 9 Dec 8 12:54 /home/foo/nfs
and
drwxr-xr-x 2 1000 1000 9 Dec 8 12:54 /home/foo/nfs
I can read and write existing files in the directory without problems.
So far, so good. Now for the problem...
If I try to create new files or directories into the directory (as user foo) I get permission denied. If I chmod 777 the directory on the server then I can write to it but the files written are owned by nobody.
If I try as root the files are also nobody but I think that's due to root squash. The directory is exported like this:
entering poll
----> /foo *(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,no_pnfs,anonuid=65534,anongid=65534,sec=krb5p,rw,secure,root_squash,no_all_squash)
Interesting that you can read and write the files without trouble, but creating files assigns the wrong ownership. You're 100% certain that you can write to the files via the NFS client? I only ask because it really sounds like the server is mapping your client user to nobody.
Have you put the container into debug mode? It's a little verbose, but there's valuable output regarding what's happening with ID mapping. Might give us a clue. Could you post your debug logs so I could take a look?
What is the underlying filesystem (on the server) of the NFS export?
Hi, well I stand a little corrected... I can write the files because they are mode 644. Files that are 600 are not writeable despite showing as owned by my uid/gid.
I think the server side is fine because I can see from the debug logs (I did have debug output enabled) that the id mapping is taking place. I can also see the mappings on the client side by doing sudo nfsidmap -l and I can see the correct names/groups against the files with ls -l and uid/git with ls -n. I also double checked with stat. It all looks correct.
So I think it's a client side issue but I am at a loss as to what it might be. I am using Arch Linux on the client and that uses the newer id resolver:
dmesg | grep id_resolver
[ 1763.186439] NFS: Registering the id_resolver key type
[ 1763.186443] Key type id_resolver registered
Here's something I tried:
$ strace touch /mnt/test.txt
...
openat(AT_FDCWD, "/mnt/test.txt", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = -1 EACCES (Permission denied)
And here's looking at the file:
$ ls -l /mnt/test.txt
-rw-r--r-- 1 john john 61 Dec 7 17:39 /mnt/test.txt
$ ls -n /mnt/test.txt
-rw-r--r-- 1 1000 1000 61 Dec 7 17:39 /mnt/test.txt
$ stat /mnt/test.txt
File: /mnt/test.txt
Size: 61 Blocks: 17 IO Block: 1048576 regular file
Device: 3ch/60d Inode: 4 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ john) Gid: ( 1000/ john)
Access: 2019-12-10 20:19:31.316270347 +0000
Modify: 2019-12-07 17:39:25.102095630 +0000
Change: 2019-12-07 17:57:09.305386162 +0000
Birth: -
$ sudo nfsidmap -l
2 .id_resolver keys found:
gid:john@mydomain.org
uid:john@mydomain.org
$ id
uid=1000(john) gid=1000(john)
$ mount | grep mnt
nfs1:/john on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=192.168.201.39,local_lock=none,addr=192.168.201.143)
On the server I see
rpc.idmapd: nfsdcb: authbuf=gss/krb5p authtype=user
rpc.idmapd: Server : (user) id "2000" -> name "john@mydomain.org"
rpc.idmapd: nfsdcb: authbuf=gss/krb5p authtype=group
rpc.idmapd: Server : (group) id "2000" -> name "john@mydomain.org"
The underlying filesystem on the server is zfs.
I have just done another test on a cleanly installed centos8 server and has the same behaviours as described previously - everything looks great, I just can't write files even if they exist and show me as owning and having write access. I've also tried creating a few additional users. Same.
I've attached a nfs server log from the session with the Centos client.
update - I have just built a new NFS server in a VM, not using the container. It works fine. I will investigate more becasue I want to get this working in the container...
Hi, just another little update, I took your Dockerfile and built a new image essentially the same but based on Arch Linux instead of Alpine.
it works fine.
The only real difference is that my one uses /usr/sbin/gssproxy -i in place of rpc.svcgss.
I will continue to investigate and report back if I find anything useful.
Progress! I'm really glad that you were able to find something to work off of, because I was stumped. I'm not familiar with gssproxy. If there's anything I can do to help you test, please let me know. And definitely please report any progress that you make!