NFS large file transfers never finish with sec=krb5p or krb5i
Description
Problem/Justification
Impact
relates to
Activity
Andrew Walker February 14, 2022 at 11:09 AM
Excellent. I'll go ahead and close out this ticket. Thank you for checking on these things.
Pascal Pascher February 14, 2022 at 10:32 AM
Everything I tested worked fine now with TrueNAS-SCALE-22.02.1-MASTER-20220213-112924. Mounting of subdirectories in nfs-shared datasets also works as expected. nfs4_getfacl shows set & inherited permissions.
Andrew Walker February 9, 2022 at 5:39 PM(edited)
Okay, I just merged the ZFS / kernel changes. This (permissions) should be working during with the next TrueNAS nightly (February 10).
You can confirm with nfs4-acl-tools on an NFS client. Do note that you will want version 0.3.7 (earlier versions have a bug that misinterprets ACE_INHERITED_ACE).
Andrew Walker February 8, 2022 at 1:03 PM
Possibly related to permissions.
NFS server WIP is here:
https://github.com/truenas/linux/pull/17
I have one more ZFS change related to secpolicy_vnode_access2() to handle fact that cred passed into inode_permissions() has CAP_SYS_ADMIN set. Should be merged by end of week.
Pascal Pascher February 8, 2022 at 12:18 PM(edited)
Some more info: I have setup FreeIPA to mount a directory in the /mnt/tank/users dataset for each user on access. I noticed that mounting of those user subdirectories works even though it is also exported with subtree_check. So my issue appears to be related to permissions/acl I assume:
Working:
Dataset: /mnt/tank/users
Mount: /mnt/tank/users/<username>
Permissions:
ls /mnt/tank/users
drwxrwxrwx 6 root root .
drwxr-xr-x 11 root root ..
drwxrwx--- 2 username usergroup <folder/username>
File: /mnt/tank/users
owner: 0
group: 0
mode: 0o40777
trivial_acl: false
ACL flags: auto-inherit:
owner@:rwxp-aARWcCos:------:allow
group@:rwxp--a-R-c-s:------:allow
everyone@:rwxp--a-R-c-s:------:allow
File: /mnt/tank/users/<username>
owner: 198600001
group: 198600001
mode: 0o40770
trivial_acl: false
ACL flags: auto-inherit:
owner@:rw-p-daARWcCo-:f-i----:allow
owner@:rwxpDdaARWcCo-:di---:allow
group@:rw-p-daARWcCo-:f-i----:allow
group@:rwxpDdaARWcCo-:di---:allow
everyone@:-------------
:fdi{{-}}--:allow
owner@:rwxp-aARWcCos:------:allow
group@:rwxp--a-R-c-s:------:allow
everyone@:------a-R-c-s:------:allow
Not working:
Dataset: /mnt/tank/backup
Sub-Dataset: /mnt/tank/backup/db
Mount: /mnt/tank/backup/db/<foldername>
Permissions:
ls /mnt/tank/backup
drwxrwsrwx 9 root root .
drwxr-xr-x 11 root root ..
drwxrws--- 2 root root db
ls /mnt/tank/backup/db
drwxr-sr-x 3 root root .
drwxrwsrwx 9 root root ..
drwxrws--- 15 <username> <usergroup> <foldername>
File: /mnt/tank/backup
owner: 0
group: 0
mode: 0o42777
trivial_acl: true
ACL flags: auto-inherit:
owner@:rwxpD-aARWcCos:-------:allow
group@:rwxpD-a-R-c-s:------:allow
everyone@:rwxpD-a-R-c-s:------:allow
File: /mnt/tank/backup/db
owner: 0
group: 0
mode: 0o42755
trivial_acl: false
ACL flags: none
owner@:rwxp-aARWcCos:------:allow
group@:r-xp--a-R-c-s:------:allow
everyone@:r-xp--a-R-c-s:------:allow
File: /mnt/tank/backup/db/<foldername>
owner: 198600010
group: 198600000
mode: 0o42770
trivial_acl: false
ACL flags: auto-inherit:
owner@:rw-p-daARWcCo-:f-i----:allow
owner@:rwxpDdaARWcCo-:di---:allow
group@:rw-p-daARWcCo-:f-i----:allow
group@:rwxpDdaARWcCo-:di---:allow
everyone@:-------------
:fdi{{-}}--:allow
owner@:rwxpD-aARWcCos:-------:allow
group@:rwxpD-a-R-c-s:------:allow
everyone@:------a-R-c-s:------:allow
Community thread: https://www.truenas.com/community/threads/rc-22-02-rc-1-2-nfs-problems.97379/
Also added to ganesha issue: https://github.com/nfs-ganesha/nfs-ganesha/issues/769
When copying large files to a nfs share mounted with sec=krb5p or krb5i file transfers get stuck. Copying from the nfs share works fine.
sec=krb5 so far has never gotten stuck.
Files copied to the share i.e. via rsync stay with their temporary name even though they have the same size as the source.
It appears the client never sends the NFS CLOSE packet which it does for sec=krb5.
I attached a link with tcpdumps from both the client and the server as well as FULL_DEBUG ganesha logs for both the failing case (krb5i) and the working case (krb5).