Nfs share and acl problem

Hello to all!
I recently installed Truenas (ip 10.1.1.2).
I have a pool with 2 disks on which I created an NFS dataset and mounted it on a Raspberry Debian with this command:
mount -F nfs -o acl 10.1.1.2:/mnt/pool1/nfs_share /mnt/backup
When I go to copy files with acl:
rsync -a -A /srv/file /mnt/backup/
Returns me this error:
set_acl: sys_acl_set_file(file, ACL_TYPE_ACCESS): Operation not supported
Thank you all in advance for your help.

run rsync with --inplace --no-perms --no-owner --no-group

Thanks @bugacha but I would like to transfer the file permissions.

I dont think its possible over NFS.

I would transfer files without and then re-apply required ACLs in TrueNAS UI. This will be much cleaner.

alternatively tar files on source, copy it over with rsync and untar it on NAS.
but you have to make sure user-ids are align to restore the permissions correctly.

I wanted to see if I was wrong in the configuration of the dataset.
I have read that NFS supports ACL but with particular combination of NFS version and Operating System.
Thanks @bugacha for your workaround but if Truenas doesn’t support ACL via NFS I need to find a more practical, less challenging solution/combination. :sweat_smile:

If you want to use POSIX ACLs over NFS, then you have to set the ACL type on the ZFS dataset to POSIX. The acl mount option for the linux NFS client is to use POSIX (not NFSv4) ACLs over the NFS protocol.

Thanks @awalkerix !
I’ve make new dataset for test, setup acl POSIX via cli:

root@truenas[~]# zfs set acltype=posixacl pool3/acltest      
root@truenas[~]# zfs get all  pool3/nfsdataset | grep acltype
pool3/nfsdataset  acltype                       posix                            inherited from pool3

I’ve mounted in linux server with:
mount -t nfs -o acl 10.1.1.2:/mnt/pool3/acltest /mnt/acldataset/

but rsync of acl file give same error:

[srv.gmmg /mnt/acldataset]# rsync -a -P -A /root/aclfile  /mnt/acldataset/
sending incremental file list
aclfile
              0 100%    0,00kB/s    0:00:00 (xfr#1, to-chk=0/1)
rsync: [receiver] set_acl: sys_acl_set_file(.aclfile.oh0k1L, ACL_TYPE_ACCESS): Operation not supported (95)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.2.7]

After set acl option in dataset, i’ve to restart some service? :thinking:

Yes, you may need to restart NFS service. What type of client are you using? BTW, generally syncing permissions / ACLs over rsync doesn’t work very well unless you’re using AD / LDAP to provide consistent IDs on machines.

You may also have to remount from client side.

Also to clarify things more explicitly:
ACLs are supported on all dataset ACL types. The NFSv4 protocol has its own distinct ACL type that is accessible through the linux utilities nfs4acl_getfacl and nfs4acl_setfacl. Linux has an option to eschew the RFC for how ACLs are handled in the protocol and use the less rich and largely incompatible POSIX1E ACL type.

I’ve restarted Truenas and client, remounted but error still exist.
Rsync or cp -a not copy acl perm! :disappointed:
Client is Debian with samba server. Acl are for samba share, user are simple internal linux users, declared in /etc/passwd file.

Do your passwd IDs lineup ?

two people mentioned this already

ok, thanks…i don’t use NFSv4 Acl…i use nfsv3

It seems that Debian does not mount with acl:

[srv.gmmg ~]# nfsstat -m
/mnt/acldataset from 10.1.1.2:/mnt/pool3/acltest
 Flags: rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.1.1.2,mountvers=3,mountport=866,mountproto=udp,local_lock=none,addr=10.1.1.2

Unless you’ve taken the steps to ensure IDs are in sync between the servers, then copying the ACL is honestly pointless. You’ll need to fix permissions once it’s done.

ok…I understand and it’s right!
But the NFS share of Truenas is for me a backup share.
I would like to copy the files from the server to Truenas so that they keep the real permissions and that’s all.
So if I had to restore a file from the Truenas to the server, the files would have all the necessary permissions as originally.

It doesnt work like that out of the box.

You have completely different systems at source and destination.

You have to synchronize users to make ACLs transferrable.

Join both into AD

I would like to copy the files from the server to Truenas so that they keep the real permissions and that’s all.

That’s probably not going to work then. NFSv3 protocol doesn’t support xattrs. You’ll strip file metadata and potentially the SMB ACL on the source (because it’s written to an xattr in the security namespace). I highly recommend familiarizing yourself with the protocol details involved before hand-rolling a backup / restore method.

Although I mainly use TrueNAS for SMB file sharing I do sometimes get requests from other SysAdmins for some NFS storage they want to reshare out using their own set of locally managed users and groups separate to our corporate AD.

I generally just create a ‘Generic’ dataset leaving root/wheel as the owner and share out with Maproot User = root and Maproot Group = wheel.

This allows the sysadmin to change permissions accordingly but naturally the TrueNAS itself has no understanding of those.

SOLVED!!!

Hi all! :slight_smile:
I am happy to have solved the problem and share the solution in case someone else has the same need.
I had read Truenas Scale has a different management of some filesystem options, such as the ACL.
First of all I upgraded the Truenas from CORE to SCALE, with precision from Core 13.0-U6.7 to Scale 24.10.2.
To upgrade I had to export the conf from the Core, install SCALE and reimport the conf.
After that I changed the options of the nfs dataset as in the screen below, enabled POSIX acl.
Restarted nfs service on Truenas, remount path in server.
Launched rsync with a test file:
rsync -a -P -A testfile /mnt/systemd/nfs/nfsdataset/
Result:

ACL correctly reported!! :partying_face:
Thank you all for your help!