ZFS not creating correct extended attributes (xattr) via samba #5568

waltersteinlein opened this Issue Jan 7, 2017 · 7 comments


None yet

2 participants

waltersteinlein commented Jan 7, 2017 edited

System information

Type Version/Name
Distribution Name CentOS
Distribution Version 7.2
Linux Kernel 3.10.0
Architecture x86_64
ZFS Version 0.7.0-rc2
SPL Version 0.7.0-rc2

Describe the problem you're observing

I've shared two identical file systems on the same pool via samba. Creating a file (through samba) on both of them result in different extended file attributes:

# getfattr test/testfile.txt 
# file: test/testfile.txt
# getfattr data/testfile.txt 
# file: data/testfile.txt

(Note: The two filesystems are data and test)

# zfs get -r xattr tank
NAME                         PROPERTY  VALUE  SOURCE
tank                         xattr     sa     local
tank/data                    xattr     sa     inherited from tank
tank/test                    xattr     sa     inherited from tank

ACLs for both files and parent directory are identical (as show by getfacl). Filesystems are mounted (by zfs) with xattr support

# mount | grep tank
tank on /tank type zfs (rw,noatime,mand,xattr,posixacl)
tank/test on /tank/test type zfs (rw,noatime,mand,xattr,posixacl)
tank/data on /tank/data type zfs (rw,noatime,mand,xattr,posixacl)

Samba configuration for both shares are identical;

   path = /tank/data
   guest ok = no
   read only = no
   browsable = yes
   inherit permissions = yes

   path = /tank/test
   guest ok = no
   read only = no
   browsable = yes
   inherit permissions = yes

As a result, I cannot change the DOS flags (such as read-only or archive) on the data share (while I can on the tank share). I can however change the extended attributes manually

# setfattr -n user.DOSATTRIB data/testfile.txt 
# getfattr data/testfile.txt 
# file: data/testfile.txt

but afterward, the DOS flags are still not changeable through samba. ZFS seems to ignore this setting.

This could very well be a samba bug, but since it works just fine on an ext4 fs I suspect there's something on the zfs side of things going wrong.

Include any warning/errors/backtraces from the system logs

No entires in syslog. Not sure what I could include to help track this down.

waltersteinlein commented Jan 7, 2017 edited

Unfortunately I cannot reproduce the problem on a different machine. There's just this one filesystem that's bugged out and every new filesystem I create on the same pool (such as 'test') above works just fine. I could work around this by re-creating the original filesystem and copying the files over, but I'd like to avoid this since it contains about 50TiB of data.
Also, I'd like to help track this down since it could happen again. I suspect there's something wrong with xattr=on and xattr=sa since the filesystem was created with xattr=on and then the setting was changed to xattr=sa.


Ok, I found out how to find the inode infomation for a particular file:

# zdb -vvvv tank/data 155207758
Dataset tank/data [ZPL], ID 46, cr_txg 97, 41.1T, 41066553 objects, rootbp DVA[0]=<3:9b052869c00:600> DVA[1]=<0:1424ff484800:600> [L0 DMU objset] fletcher4 lz4 LE contiguous unique double size=800L/200P birth=2895887L/2895887P fill=41066553 cksum=154abe7f32:6d9c1966300:1411549ac3557:2a731bf9e53fbe

    Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
 155207758    1    16K  17.5K  3.50K     512  17.5K  100.00  ZFS plain file
                                               240   bonus  System attributes
        dnode maxblkid: 0
        path    /shelf.mel
        uid     101265
        gid     104188
        atime   Thu Dec 22 18:03:25 2016
        mtime   Thu Dec 22 18:03:25 2016
        ctime   Fri Jan  6 22:58:44 2017
        crtime  Thu Dec 22 18:03:25 2016
        gen     2607116
        mode    100775
        size    17750
        parent  390353
        links   1
        pflags  40800000004
        xattr   155207759
        SA xattrs: 56 bytes, 1 entries

                user.DOSATTRIB = 
Indirect blocks:
               0 L0 2:150008e2f000:1200 4600L/a00P F=1 B=2607116/2607116

                segment [0000000000000000, 0000000000004600) size 17.5K

so the DOSATTRIB is empty while is is valid on the 'test' filesystem mentioned above.


Ok, even when setting the correct user.DOSATTRIB user.SAMBA_PAI and security.NTACL values, it doesn't work. Could it somehow be that there's still xattr data in the direcotry that zfs uses if xattr=on and that somehow interferes with the xattr data in the inodes?


Hmm, the part that reads

               0 L0 EMBEDDED et=0 200L/53P B=2896860

                segment [0000000000000000, 0000000000000200) size   512

is not present on the files of the 'working' filesystem.


And I'm getting a ton of

WARNING: ZFS: inode ffff881ca3c39e38 has xattr "user.DOSATTRIB" in both SA and dir

in the kernel log on lots of different inodes :(


Thanks for the input. Could you be a bit more verbose?
The tl;dr version of my problem is: Got a file, can't set the DOS attributes on one filesystem, works fine when copying the file to another file system. ACLs work fine, it's just the DOS attributes. I suspect that's because those are stored in SA as well as dir.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment