umask ignored on NFSv4.2 mounts

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

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

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 https://bugzilla.redhat.com/show_bug.cgi?id=1667761.

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

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.