Hello I'm looking for help on this issue I've experienced on Unraid 7.1.0-beta.1 whilst using ZFS.

 

I have a ZFS pool consisting of 8 SSDs in a RaidZ1 configuration.

 

When I setup the pool I had set the xattr property to xattr=sa.

 

However after updating Unraid to 7.1.0 beta 1 and updating the ZFS pool to the latest version, this property seems to always be set to xattr=on regardless of my attempts to change it.

 

Find below the transcript of me attempting to change the property using the console.

 

root@Servername:~# zfs get -r xattr poolname
NAME                PROPERTY  VALUE  SOURCE
poolname               xattr     on     local
poolname/dataset       xattr     on     local
root@Servername:~# zfs set xattr=sa poolname
root@Servername:~# zfs get -r xattr poolname
NAME                PROPERTY  VALUE  SOURCE
poolname               xattr     on     local
poolname/dataset       xattr     on     local
root@Servername:~# 

 

As you can see, even though the command appears to work no change is made to the pool or dataset properties.

 

Any help would be greatly appreciated.

 

EDIT

 

I have created a new topic under the bug reports section for prerelease versions of Unraid. If deemed necessary I will remove this post as to not have duplicate posts.

Edited March 22, 20251 yr by GiulioCD

? why stay on the beta when v7 is in stable release. I would have you move to stable v7.0.1 and try again. Beta had some things they were testing and may not be fully using the zfs config for file permission.

 

Other check / troubleshooting:

 

Verify ZFS Feature Flags

Check if any new feature flags were enabled in the pool upgrade that might affect xattr handling

zpool get all poolname | grep feature

-Look specifically for anything related to extended attributes or dataset compatibility.

 

 

Check Dataset-Specific Properties

Sometimes dataset-level settings override pool-level defaults

zfs get all poolname/dataset | grep xattr

Try setting xattr=sa explicitly on the individual dataset:

 

zfs set xattr=sa poolname/dataset
zfs get xattr poolname/dataset

*Changing poolname/dataset to your poll and datset name... 

 

 

Double check with another app:

 

Use zdb to Inspect Internals

This is more advanced and read-only, but can provide insight:

zdb -C poolname | grep xattr

Or to inspect specific dataset configurations:

zdb -ddddd poolname/dataset | grep xattr

*Note: Output might be verbose or not show much if the property is being masked or ignored by a bug.

 

 

Inspect Actual xattr Storage Method

You can check how the system is storing extended attributes using getfattr (on Linux):

getfattr -d somefile

or try:

xattr -l somefile

*-A file in the dataset to check the attribute...

 

Create New Dataset with xattr=sa as a test

This will help verify if it’s a dataset-specific bug or a general one:

zfs create -o xattr=sa poolname/testdataset
zfs get xattr poolname/testdataset

Does it still report on? If so, it’s likely a bug introduced in this beta.

 

There are also read write execute permission on the zfs datasets as well... you may also be fighting them... Example moving from trueness into unraid...
As ZFS datasets also obey standard POSIX permissions, so even if xattr=sa is set correctly, access might still be blocked or weird due to ownership and permission bits. Let's hit it from both angles.... Here's how you can set owner to nobody, group to users, and permissions to 777 on your ZFS dataset using ZFS-compatible commands:

 

Here's how you can set owner to nobody, group to users, and permissions to 777 on your ZFS dataset using ZFS-compatible commands:

chown -R nobody:users /mnt/poolname/dataset
chmod -R 777 /mnt/poolname/dataset

*Setting docer safe permission for unriad...

-This gives read, write, and execute to owner, group, and others, across all files and directories. Use with caution if you care about security/access control.

 

ZFS Delegated Permissions (optional) 

*Things I would have you set and try... due to potentail permission issue...

 

If you ever want to assign permissions on the ZFS dataset level (less common for home/unRAID users), you could use:

zfs allow poolname/dataset everyone create,read,write,mount

or revoke with:

zfs unallow poolname/dataset

 

After Setting Permissions verify:

ls -ld /mnt/poolname/dataset

and example of an expected output:

drwxrwxrwx  nobody users ...

 

 

Thank you for the detailed response. A lot of the information you provided is extremely useful and I will take note of it.

 

As for the issue, it would seem that upgrading pools to ZFS 2.3.0 will cause this behavior :

 

On 3/24/2025 at 7:22 AM, JorgeB said:

Confirmed it's just a display issue, apparently with OpenZFS 2.3 xattr=on is the same as xattr=sa

 

https://github.com/openzfs/zfs/discussions/16996#discussioncomment-11981838

 

I will proceed to close this issue but I want to thank you for the detailed response.

On 3/22/2025 at 9:25 AM, bmartino1 said:

? why stay on the beta when v7 is in stable release. I would have you move to stable v7.0.1 and try again. Beta had some things they were testing and may not be fully using the zfs config for file permission.

 

Just to clarify I'm using the latest beta build v7.1.0-beta1 not v7.0.1.

 

EDIT

 

Quote

Or to inspect specific dataset configurations:

zdb -ddddd poolname/dataset | grep xattr

 

 

According to the console output after running this command I get the following repeated multiple times :

 

 SA xattrs: 80 bytes, 1 entries

 

I believe this is proof that the dataset is in fact using xattrs=sa.

 

This alleviates my concern, thanks for the commands.

Edited March 26, 20251 yr by GiulioCD