umask ignored on NFSv4.2 mounts

[Michael Shannon]

After upgrading to kernel 4.15.0-24-generic (on Ubuntu 18.04 LTS) NFSv4.2 mounts ignore the umask when creating files and directories. Files get permissions 666 and directories get 777. Therefore, a umask of 000 is seemingly being forced when creating files/directories in NFS mounts. Mounting with noacl does not resolve the issue.

How to replicate:

1. Mount an NFS share (defaults to NFSv4.2)
2. Ensure restrictive umask: umask 022
3. Create directory: mkdir test_dir
4. Create file: touch test_file
5. List: ls -l

The result will be:
drwxrwxrwx 2 user user 2 Jul 2 12:16 test_dir
-rw-rw-rw- 1 user user 0 Jul 2 12:16 test_file

while the expected result would be
drwxr-xr-x 2 user user 2 Jul 2 12:16 test_dir
-rw-r--r-- 1 user user 0 Jul 2 12:16 test_file

Bug does not occur when mounting with any of:
  vers=3
  vers=4.0
  vers=4.1

I have a suspicion this is related to: https://tools.ietf.org/id/draft-ietf-nfsv4-umask-03.html
But since the server does not have ACL's enabled, and mounting with noacl does not resolve the issue this is unexpected behavior.

Both server and client are running kernel 4.15.0-24-generic on Ubuntu 18.04 LTS. NFS package versions are:

nfs-kernel-server 1:1.3.4-2.1ubuntu5
nfs-common 1:1.3.4-2.1ubuntu5

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Quentin (quantumhpc)]

As a workaround/fix, the umask is respected if you set the acl to the zfs exported pool"
zfs set acltype=posixacl ...

[W. Michael Petullo (mike-flyn)]

I am having a similar problem on Fedora, but the documentation is sparse. As a workaround, I presently mount using NFSv4.1 rather than 4.2. I can neither find precise documentation on (1) what is going on nor (2) how to restore the behavior where the process umask comes into play when creating a file or directory.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1667761.

[Scott Emmons (lscotte)]

I can confirm this issue, on Ubuntu Bionic - server is 4.15.0-43-generic, client is 4.15.0-45-generic. Server filesystem is ZFS (using nfs-kernel-server for export). Mounting with vers=4.1 works around it as noted above.

[Mason Loring Bliss (y-mason)]

I can confirm that "zfs set acltype=posixacl foo/bar/" is an effective workaround. It appears to be
unset by default.

root@box /root# zfs set acltype=posixacl pool/srv/thing
root@box /root# zfs get acltype pool/srv
NAME PROPERTY VALUE SOURCE
pool/srv acltype off default
root@box /root# zfs get acltype pool/srv/thing
NAME PROPERTY VALUE SOURCE
pool/srv/thing acltype posixacl local

Thanks, Quentin.

[Luis Felipe Marzagao (dulinux)]

I can confirm setting acltype to posixacl on the dataset shared via NFS fixes the issue.

[Databay (rs-databay)]

Same for me, setting posixacl on ZFS exported via NFS is a workaround

[Seth Arnold (seth-arnold)]

The default NFSv4 acls may be a poor choice on ZOL. This keeps biting people unexpectedly, I wonder how many people this has affected and they never spot it?

Thanks

[Richard Laager (rlaager)]

seth-arnold, the ZFS default is actltype=off, which means that ACLs are disabled. (I don't think the NFSv4 ACL support in ZFS is wired up on Linux.) It's not clear to me why this is breaking with ACLs off.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Colin Ian King (colin-king)]

I'm reluctant to change the ZFS default to make NFSv4 work out of the box as this may cause regressions for users expecting the default. I'm making this bug a wish until somebody can produce compelling evidence why we should change the default and how this won't affect the user experience for the non-NFSv4 users.