My System: ElectricEel-24.10.2.1
In my plans to transition from SMB to NFS shares due to problems with hardlink detection in SMB, I created a test dataset with the following params:
- Path:
/mnt/nas/test - Dataset Preset:
Generic(this is how my working dataset has been created) - ACL Type:
SMB/NFSv4 - ACL Mode:
Restricted
I have several credentials that have been using the smb share so far:
- Users:
chrolish (3000), share (3001) - Groups:
share (3001) - both users are members of the group
share
To set up my test environment, I created several directories inside the dataset using the root shell, here is the relevant output of ls -l:
drwxrwx--- 2 chrolish share 2 Jun 14 18:14 from_truenas_chrolish
drwxrwx--- 2 root share 2 Jun 14 18:14 from_truenas_root
drwxrwx--- 2 share share 2 Jun 14 18:14 from_truenas_share
I successfully tested access locally with all 3 different users.
I set up an ACL list on the dataset, allowing full control access to owner@ - share, group@ - share as well as the group share specifically, using the GUI. I applied the ACL recursively, leaving Apply Owner/Group unchecked, as I wanted to leave them as above.
This resulted in the ACL looking like this for all 3 directories, except for the owner id, obviously:
root@truenas[/mnt/nas/test]# nfs4xdr_getfacl from_truenas_share -v
# File: from_truenas_share
# owner: 3001
# group: 3001
# mode: 0o40770
# trivial_acl: false
# ACL flags: none
group:share:read_data/write_data/execute/append_data/delete_child/delete/read_attributes/write_attributes/read_xattr/write_xattr/read_acl/write_acl/write_owner/synchronize:file_inherit/dir_inherit/inherited:allow
owner@:read_data/write_data/execute/append_data/delete_child/delete/read_attributes/write_attributes/read_xattr/write_xattr/read_acl/write_acl/write_owner/synchronize:file_inherit/dir_inherit/inherited:allow
group@:read_data/write_data/execute/append_data/delete_child/delete/read_attributes/write_attributes/read_xattr/write_xattr/read_acl/write_acl/write_owner/synchronize:file_inherit/dir_inherit/inherited:allow
So I assume the ACL has been applied correctly.
The path was exported using NFSv4 only. I don´t plan on syncing all user and group ids on all my systems, nor am I considering setting up a directory service right now. With that in mind, I opted to squash all clients to the local user share (3001) and the group share (3001), which I figured would allow me to access everything at least owned by the group share as I observed testing locally.
The resulting export looked like this:
"/mnt/nas/test"\
*(sec=sys,rw,anonuid=3001,anongid=3001,all_squash,no_subtree_check)
On the client-side, the share was mounted successfully using the defaults. I was able to cd into the mountpoint and even create a directory from_client. It was correctly created as owned by 3001:3001, as intended.
root@client:/mnt/test# ls -l
total 3
drwxrwx--- 2 3001 3001 2 Jun 14 16:31 from_client
drwxrwx--- 2 3000 3001 2 Jun 14 16:14 from_truenas_chrolish
drwxrwx--- 2 root 3001 2 Jun 14 16:14 from_truenas_root
drwxrwx--- 2 3001 3001 2 Jun 14 16:14 from_truenas_share
But once I try to access or read the acl of the directories owned by different users than 3001, I am getting permission denied errors:
root@client:/mnt/test# ls -l *
from_client:
total 0
ls: cannot open directory 'from_truenas_chrolish': Permission denied
ls: cannot open directory 'from_truenas_root': Permission denied
from_truenas_share:
total 0
From where I am allowed to read the ACL on the client, it looks like this:
root@client:/mnt/test# nfs4_getfacl from_truenas_share/
A:fdgO:3001:rwaDdxtTnNcCoy
A:fdO:OWNER@:rwaDdxtTnNcCoy
A:fdgO:GROUP@:rwaDdxtTnNcCoy
So that is basically it: I am unable to access data owned by the same group although I actually should (afaik).
What forces could be at play here? I even tried setting up user-group-relations as they are on the server, but to no avail!
I am at my wits end here and really sank a lot of hours into this. Any help or pointer in the right direction would be appreciated 
