Description of problem: I have an NFS share which I mount from a Fedora workstation. When I mount the share using NFSv4.2, I find that the process umask is ignored when creating files and directories within the share. Files are created with 666 permissions, and directories are created with 777 permissions. Mounting the same share with NFSv4.1 rather than 4.2 works fine. Version-Release number of selected component (if applicable): nfs-utils-2.3.3-1.rc2.fc29.x86_64 How reproducible: Every time Steps to Reproduce: 1. Mount an NFSv4.2 share at /mnt 2. mkdir /mnt/foo 3. ls -ld /mnt/foo Actual results: Permissions are 777. Expected results: Permissions should be 755, due to a process umask of 0022. Additional info: The NFS server runs OpenWrt. This seems related to a similar Ubuntu report: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736 I suspect this results from changes due to the RFC "Allowing Inheritable NFSv4 ACLs to Override the Umask:" https://tools.ietf.org/id/draft-ietf-nfsv4-umask-03.html
THis would be expected if there were some kind of inheritable acls set on the export, can you tell if that's the case? What kernel (from uname -a) is the server running, and what's the exported filesystem? To start debugging this, I'd recommend looking running wireshark to sniff traffic while running your reproducer (mount, mkdir) and compare to what's expected from the umask RFC. Somewhere there should be a getattr from the client for the supported_attrs attribute, and the reply from the server will probably indicate support for the new mode_umask attribute. If you find the CREATE operation that creates the new directory, you should see the client set the mode_umask attribute, with the mode part set to the open mode and the umask to the process umask. If those values look right, then the problem is likely on the server side.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still present in Fedora 31. The server is an OpenWrt build running 4.19.78 on x86_64. See also: https://bugs.openwrt.org/index.php?do=details&task_id=2581 for more information about the client.
Created attachment 1634077 [details] NFSv4.2 interaction packet capture This captures the network traffic associated with the following commands: mount -o vers=4.2 golem.flyn.org:/home/mike /mnt touch /mnt/foo ls -l /mnt/foo umount /mnt
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to W. Michael Petullo from comment #3) > Still present in Fedora 31. > > The server is an OpenWrt build running 4.19.78 on x86_64. > > See also: https://bugs.openwrt.org/index.php?do=details&task_id=2581 for > more information about the client. umask support went into 4.10, so that server should be sufficient. It could be 22cf8419f131 "nfsd: apply umask on fs without ACL support" depending on the exported filesystem.
(In reply to W. Michael Petullo from comment #4) > Created attachment 1634077 [details] > NFSv4.2 interaction packet capture > > This captures the network traffic associated with the following commands: > > mount -o vers=4.2 golem.flyn.org:/home/mike /mnt > touch /mnt/foo > ls -l /mnt/foo > umount /mnt If the problem's still there--a binary capture would be more useful. E.g., "tcpdump -s0 -wtmp.pcap", then attach tmp.pcap.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Something in Fedora (client) or OpenWrt (server) fixed this. I am presently using Fedora 33 and OpenWrt master (r14985-4d4ef1058c).