Strange ACL error on one Dataset - Error: [EFAULT] Winacl clone failed with error

C800

Cadet
Joined
Sep 16, 2020
Messages
6
I'm new to FreeNAS and have the following build:
  • FreeNAS-11.3-U4.1
  • Motherboard: SuperMicro X11SSL-F
  • CPU make and model: Intel Core i3-6320 Processor
  • RAM quantity: Kingston16GB 2666MHz DDR4 ECC
  • Hard drives: Boot Drive Crucial BX500 120 GB SSD, Pool 1 - 2 x shucked WD 8 TB Elements (mirror), Pool 2, 150GB SATA 2.5"
It is a fairly straightforward home system with one main mirrored pool, backed up to an external SFTP drive using the Duplicati plugin (in a jail running on another pool on a small 150GB SATA drive). In due course, once everything is up-and-running correctly I will have another similar ‘off-site’ backup.

Prior to migrating my data from my old XyXEL NSA310 NAS, I tested the process of creating users/groups, setting ACL’s for SAMBA shares, encrypting the main pool, correctly setting mount points for Duplicati in the jail, restoring from both snapshots and Duplicati backups.

Once I had everything working how I wanted it (and was confident that the backup/restore process functioned as expected) I added the rest of my datasets / shares and copied my data across. All is working fine apart from one dataset, which appears to be having a problem with updating ACL’s.

The dataset in question [/mnt/neo/craig] is the original one that I was doing my various tests with before transferring data across to. It was created as a Share Type: SMB. The problem is that when I try to update the ACL’s (Apply Permissions Recursively) it gives the following error:


Code:
Saving ACLs

Error: [EFAULT] Winacl clone on path /mnt/neo/craig failed with error: [winacl: .zfs: acl_set_file() failed: Operation not supported winacl: .zfs: set_acl() failed: Operation not supported]



None of the additional datasets in the same pool exhibit this behaviour and ACL’s are updated as expected.

I have replicated the existing data in the problem dataset to a new dataset. The same issue issue occurs when I try to change ACL’s on that replication. If I create a new dataset then no problem (but really I’d like to keep the same name).

I also tried disconnecting the pools, reinstalling a fresh instance of FreeNAS, importing the pools, but still the problem remains.

Is there a way of rectifying this problem (sorry for the long post, but I wanted to make it clear what the issue was!)?

Thanks,

Craig
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
I'm new to FreeNAS and have the following build:
  • FreeNAS-11.3-U4.1
  • Motherboard: SuperMicro X11SSL-F
  • CPU make and model: Intel Core i3-6320 Processor
  • RAM quantity: Kingston16GB 2666MHz DDR4 ECC
  • Hard drives: Boot Drive Crucial BX500 120 GB SSD, Pool 1 - 2 x shucked WD 8 TB Elements (mirror), Pool 2, 150GB SATA 2.5"
It is a fairly straightforward home system with one main mirrored pool, backed up to an external SFTP drive using the Duplicati plugin (in a jail running on another pool on a small 150GB SATA drive). In due course, once everything is up-and-running correctly I will have another similar ‘off-site’ backup.

Prior to migrating my data from my old XyXEL NSA310 NAS, I tested the process of creating users/groups, setting ACL’s for SAMBA shares, encrypting the main pool, correctly setting mount points for Duplicati in the jail, restoring from both snapshots and Duplicati backups.

Once I had everything working how I wanted it (and was confident that the backup/restore process functioned as expected) I added the rest of my datasets / shares and copied my data across. All is working fine apart from one dataset, which appears to be having a problem with updating ACL’s.

The dataset in question [/mnt/neo/craig] is the original one that I was doing my various tests with before transferring data across to. It was created as a Share Type: SMB. The problem is that when I try to update the ACL’s (Apply Permissions Recursively) it gives the following error:


Code:
Saving ACLs

Error: [EFAULT] Winacl clone on path /mnt/neo/craig failed with error: [winacl: .zfs: acl_set_file() failed: Operation not supported winacl: .zfs: set_acl() failed: Operation not supported]



None of the additional datasets in the same pool exhibit this behaviour and ACL’s are updated as expected.

I have replicated the existing data in the problem dataset to a new dataset. The same issue issue occurs when I try to change ACL’s on that replication. If I create a new dataset then no problem (but really I’d like to keep the same name).

I also tried disconnecting the pools, reinstalling a fresh instance of FreeNAS, importing the pools, but still the problem remains.

Is there a way of rectifying this problem (sorry for the long post, but I wanted to make it clear what the issue was!)?

Thanks,

Craig
Okay. That error means that the FreeBSD system call acl_set_file() failed on the file ".zfs", and it failed with an error "EOPNOTSUP". This is somewhat expected (since you can't change permissions on the hidden .zfs directory) Perhaps you have enabled snapdir visibilty on this dataset (ZFS dataset property)? If so, try switching it off, and then retry.

If this fixes the issue, then I'll make a change to ensure that we prune branches from the FTS tree in this case.
 

C800

Cadet
Joined
Sep 16, 2020
Messages
6
Okay. That error means that the FreeBSD system call acl_set_file() failed on the file ".zfs", and it failed with an error "EOPNOTSUP". This is somewhat expected (since you can't change permissions on the hidden .zfs directory) Perhaps you have enabled snapdir visibilty on this dataset (ZFS dataset property)? If so, try switching it off, and then retry.

If this fixes the issue, then I'll make a change to ensure that we prune branches from the FTS tree in this case.

Superb! Yes, thank you, that has fixed the problem. I had the snapshot directory set to visible (an excellent feature by-the-way). By setting it back to invisible I could change ACL permissions and then revert the visibility.

Thank you for the quick answer.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
Superb! Yes, thank you, that has fixed the problem. I had the snapshot directory set to visible (an excellent feature by-the-way). By setting it back to invisible I could change ACL permissions and then revert the visibility.

Thank you for the quick answer.
Snapdir visibility to a double-edged sword. It can make some things really easy, but many CLI applications don't handle it well. For instance, you probably don't want rclone to start copying that path.

BTW, having snapdir visibility off does not prevent access to ".zfs/snapshot". If you are sharing /mnt/tank/SHARE as "SMB", then you can navigate directly to "\\<IP>\SMB\.zfs\snapshot\"
 

C800

Cadet
Joined
Sep 16, 2020
Messages
6
Snapdir visibility to a double-edged sword. It can make some things really easy, but many CLI applications don't handle it well. For instance, you probably don't want rclone to start copying that path.

BTW, having snapdir visibility off does not prevent access to ".zfs/snapshot". If you are sharing /mnt/tank/SHARE as "SMB", then you can navigate directly to "\\<IP>\SMB\.zfs\snapshot\"

Ah OK, good point, thank you. I'd had to make sure not to include "hidden files" with my Duplicati backups for exactly that reason, so that I didn't end up with excessively large files from the snapshots, but just navigating to the link is a much better idea.
VMT.
 
Top