umask ignored on NFSv4.2 mounts

Bug #1779736 reported by Michael Shannon on 2018-07-02
This bug affects 7 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
nfs-utils (Ubuntu)
zfs-linux (Ubuntu)

Bug Description

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:

I have a suspicion this is related to:
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

description: updated
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in nfs-utils (Ubuntu):
status: New → Confirmed
Quentin (quantumhpc) wrote :

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) wrote :

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

Scott Emmons (lscotte) wrote :

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.

Changed in linux (Ubuntu):
status: New → Confirmed
Mason Loring Bliss (y-mason) wrote :

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
pool/srv acltype off default
root@box /root# zfs get acltype pool/srv/thing
pool/srv/thing acltype posixacl local

Thanks, Quentin.

Luis Felipe Marzagao (dulinux) wrote :

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

Databay (rs-databay) wrote :

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

Seth Arnold (seth-arnold) wrote :

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?


Richard Laager (rlaager) wrote :

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) wrote :

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

Changed in zfs-linux (Ubuntu):
status: New → Confirmed
Colin Ian King (colin-king) wrote :

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.

Changed in zfs-linux (Ubuntu):
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.