Strange behavior on MacOS + SMB share

[yemartin]

While working on a MacOS port, I just found a weird bug when updating tags on a Samba share. I am wondering if this bug is introduced by some MacOS + SMB interaction, or if it is preexisting. Here is the behavior I am seeing:

When updating an outdated tag on the Mac's main filesystem, the update works, and the next run of cshatag reports <ok>:

yemartin at iMac in ~/src/cshatag-master
$ cshatag test.bin
<outdated> test.bin
 stored: d8c2284963814db0cc2e9d49d96af3139bbc1fee0c43f6f45004863c8e10bdc5 1560059961.626701323
 actual: c2bd3e9a8195e2fe3ed99864752c5edb449b8c43beb7a51dcd3b6e28258b955b 1560060120.445768395

yemartin at iMac in ~/src/cshatag-master
$ cshatag test.bin
<ok> test.bin

When doing the same thing on an SMB-mounted Samba share, the update does not work: instead, the xattrs are removed. The next run of cshatag reports a missing flag ("stored: 00000..."), and this time, it sets the xattrs succesfully. Another (third) run of cshatag reports <ok>:

yemartin at iMac in /Volumes/Organizer
$ cshatag test.bin
<outdated> test.bin
 stored: d8c2284963814db0cc2e9d49d96af3139bbc1fee0c43f6f45004863c8e10bdc5 1560059979.000000000
 actual: c2bd3e9a8195e2fe3ed99864752c5edb449b8c43beb7a51dcd3b6e28258b955b 1560060125.000000000

yemartin at iMac in /Volumes/Organizer
$ cshatag test.bin
<outdated> test.bin
 stored: 0000000000000000000000000000000000000000000000000000000000000000 0000000000.000000000
 actual: c2bd3e9a8195e2fe3ed99864752c5edb449b8c43beb7a51dcd3b6e28258b955b 1560060125.000000000

yemartin at iMac in /Volumes/Organizer
$ cshatag test.bin
<ok> test.bin

Is this a known issue with SMB or Samba? If not, can someone confirm whether this can be reproduced with Linux + Samba share?

(In case it matters: the protocol negotiated between the Mac and Samba server was SMB_3.02)

Thank you.

[rfjakob]

Seems to work fine here on a Linux server + client combination:

$ mount | grep samba-test
//127.0.0.1/samba-test on /mnt/samba-test type cifs (rw,relatime,vers=3.1.1,cache=strict,username=jakob,uid=1026,forceuid,gid=1026,forcegid,addr=127.0.0.1,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,user=jakob)

$ cd /mnt/samba-test
$ cshatag test.bin 
<outdated> test.bin
 stored: 0000000000000000000000000000000000000000000000000000000000000000 0000000000.000000000
 actual: d2e25e06f8d56589e80c8b75b4061651c543fe5c3e202481b77ebc8028612367 1560085809.832497200

$ cshatag test.bin 
<ok> test.bin

[rfjakob]

Also looks OK when mounting with "vers=1.0" so it uses SMB1 protocol:

$ mount | grep samba-test
//127.0.0.1/samba-test on /mnt/samba-test type cifs (rw,relatime,vers=1.0,cache=strict,username=jakob,uid=1026,forceuid,gid=1026,forcegid,addr=127.0.0.1,soft,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1,user=jakob)

This was tested on Fedora 30, versions are:

$ smbd --version
Version 4.10.2

$ uname -r
5.0.11-300.fc30.x86_64

[yemartin]

Thank you for checking @rfjakob, I will put a workaround only in the MacOS code then.

Should we keep this issue open, so others can be alerted to the problem? Maybe someone else can suggest a solution.

[yemartin]

For the record: a workaround (calling fsetxattr twice) is currently implemented in #11.

[yemartin]

1) Making sure we are looking at the same thing

@rfjakob I just realized one thing: maybe you tested only with creating a new tag? The sample you posted in #8 (comment) was:

$ cd /mnt/samba-test
$ cshatag test.bin 
<outdated> test.bin
 stored: 0000000000000000000000000000000000000000000000000000000000000000 0000000000.000000000
 actual: d2e25e06f8d56589e80c8b75b4061651c543fe5c3e202481b77ebc8028612367 1560085809.832497200

$ cshatag test.bin 
<ok> test.bin

This works for me too, but this is creating a new tag. The issue happen only when updating a preexisting but outdated tag.

To be sure we are on the same page, here is a oneliner to copy-paste (the sleep 3 is to work around the low time resolution on

rm test.bin; \
touch test.bin \
&& cshatag test.bin \
&& sleep 3 \
&& echo "foo" >> test.bin \
&& cshatag test.bin \
&& cshatag test.bin

The correct final bit of output should be:

<ok> test.bin

but without the double-call to fsetxattr and when connecting to that SMB_3 share, my output is:

<outdated> test.bin
 stored: 0000000000000000000000000000000000000000000000000000000000000000 0000000000.000000000
 actual: b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c 1560140293.000000000

2) Additional info

For the record, I was not able to reproduce this issue when running a Mac + SMB_1 share setup. So it may be more of an SMB_3 issue rather than a Mac issue.

[yemartin]

@rfjakob Can you help me a bit? Investigating this issue, I am trying to mount my NAS SMB share on a Linux VM I just got running on my Mac (Linux Mint 19.1 fresh install). The Samba server on the NAS obviously supports extended attributes since they work fine when the share is mounted on the Mac.

However, I cannot seem to be able to get extended attributes working at all when mounting the share in the Linux VM. Here is my mount command:

$ sudo mount -t cifs //192.168.1.10/Organizer /mnt/Organizer \
    -o "username=admin,user_xattr,acl"

But this does not work at all for me:

$ sudo setfattr -n user.foo -v bar /mnt/Organizer/test.bin
setfattr: /mnt/Organizer/test.bin: Operation not supported

How did you mount your SMB share on Linux to get the extended attributes working?

[yemartin]

I just booted Fedora 30 (5.0.9-301.fc30.x86_64) in another VM, but I am getting the same Operation not supported error.

[rfjakob]

I mounted like this:

$ sudo mount -t cifs //127.0.0.1/samba-test -o vers=3,user=jakob,uid=jakob,gid=jakob /mnt/samba-test

I get this output from your testcase:

$ rm test.bin; touch test.bin && cshatag test.bin && sleep 3 && echo "foo" >> test.bin && cshatag test.bin && cshatag test.bin
<outdated> test.bin
 stored: 0000000000000000000000000000000000000000000000000000000000000000 0000000000.000000000
 actual: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 1560281420.480858900
<outdated> test.bin
 stored: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 1560281420.480858900
 actual: b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c 1560281423.493661600
<ok> test.bin