On Mon, 26 Nov 2018 at 15:07, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Sat, Nov 24, 2018 at 08:18:40PM -0500, Byron Stanoszek wrote: > > I would like to report a problem with NFS v4.2: the umask seems to be > > getting dropped when creating files. This works as expected when > > connecting with a v4.1 client or any version prior. > > In 4.2 the umask is sent in a separate attribute, in earlier versions > the umask and open mode are combined by the client and only the result > is sent. > > So probably either the client is sending just the open mode (with the > umask applied) and neglecting to send the umask, or it's sending them > both correctly and the server is ignoring the umask. > > Watching the network traffic in wireshark might help determine which > side is at fault. Right, a network dump (tcpdump -w) of the incorrect operation(s) would be great so that we can have a look with wireshark. > > Here is an example shell session: > > > > root@client:~> mount -overs=4.1 lnxsvr1:/users/files /users/files > > root@client:~> cd /users/files > > root@client:/users/files> ls blah > > ls: cannot access 'blah': No such file or directory > > root@client:/users/files> touch blah > > root@client:/users/files> ls blah > > 0 -rw-r--r-- 1 root root 0 Nov 24 19:54 blah > > root@client:/users/files> rm blah > > root@client:/users/files> cd > > root@client:~> grep files /proc/mounts > > lnxsvr1:/users/files /users/files nfs4 rw,noatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.11,local_lock=none,addr=10.0.0.2 0 0 > > root@client:~> umount /users/files > > root@client:~> mount -overs=4.2 lnxsvr1:/users/files /users/files > > root@client:~> cd /users/files > > root@client:/users/files> ls blah > > ls: cannot access 'blah': No such file or directory > > root@client:/users/files> touch blah > > root@client:/users/files> ls blah > > 0 -rw-rw-rw- 1 root root 0 Nov 24 19:54 blah > > root@client:/users/files> rm blah > > root@client:/users/files> cd > > root@client:~> grep files /proc/mounts > > lnxsvr1:/users/files /users/files nfs4 rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.0.11,local_lock=none,addr=10.0.0.2 0 0 > > root@client:~> umount /users/files > > root@client:~> umask > > 0022 > > > > The "blah" file gets created with mode 0644 (as expected) with v4.1, but mode > > 0666 with v4.2. I've seen the problem so far across Linux 4.18.x and 4.19.x. It > > happens as any UID and not just "root". > > > > The file is created via this system call: > > > > openat(AT_FDCWD, "blah", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_LARGEFILE, 0666) = 3 > > > > A cursory Google search revealed this URL which suggests the problem has been > > happening since Linux 4.15: > > > > https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736 > > > > I've attached a copy of my Linux kernel config used on both server and client. > > Perhaps not having NFS ACLs enabled is the cause: > > > > root@client:/usr/src/linux> grep ACL .config > > # CONFIG_EXT4_FS_POSIX_ACL is not set > > # CONFIG_BTRFS_FS_POSIX_ACL is not set > > CONFIG_FS_POSIX_ACL=y > > # CONFIG_TMPFS_POSIX_ACL is not set > > # CONFIG_NFS_V3_ACL is not set > > # CONFIG_NFSD_V3_ACL is not set > > I can't see off the top of my head why that would be related. But I > doubt that configuration gets much testing, so it's worth a look whether > we're doing something weird in that case.... What filesystem type is /users/files on on lnxsvr1? Thanks, Andreas
