idmapping new files always nobody about docker-nfs-server

[ehough]

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!

[ehough]

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?

[johnlane]

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:[email protected]
  uid:[email protected]
$ 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 "[email protected]"
rpc.idmapd: nfsdcb: authbuf=gss/krb5p authtype=group
rpc.idmapd: Server : (group) id "2000" -> name "[email protected]"

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.

nfs.log

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...

[johnlane]

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.

Dockerfile.txt

entrypoint.sh.txt

I will continue to investigate and report back if I find anything useful.