Tested on FreeBSD and Debian servers running Samba 4.8/4.9. Apparently, OSX High Sierra introduced new behavior where "preview" in Finder will set a RH lease on the AFP_Resource stream that doesn't get released. Example smbstatus output:
Pid Uid DenyMode Access R/W Oplock SharePath Name Time
68450 1002 DENY_WRITE 0x20001 RDONLY LEASE(RH) /zroot/samba foo2/template_storyboard.psd:AFP_Resource Thu Sep 27 16:39:40 2018
68450 1002 DENY_NONE 0x100081 RDONLY NONE /zroot/samba foo2 Thu Sep 27 16:39:32 2018
68450 1002 DENY_NONE 0x0 RDONLY NONE /zroot/samba foo2/template_storyboard.psd Thu Sep 27 16:39:40 2018
68451 1002 DENY_NONE 0x100081 RDONLY NONE /zroot/samba . Thu Sep 27 16:26:33 2018
The lock isn't released until the SMB session ends.
This has the effect of causing directory renames to fail (access denied) unless we've set FSP_POSIX_FLAGS_RENAME (i.e. fruit).
Unfortunately, the fix in 13451 (Fail renaming file if that file has open streams) makes this situation worse. Since the open streams never get closed, users can no longer rename files once they've been opened in this particular Finder mode. I've tested this with vfs_fruit + streams_xattr, and the different ways of storing the AFP_Resource stream.
I'm not sure if this is an OS-X bug, a samba bug, or some mixture of both. I'm happy to provide any collateral you need, but the issue is fairly trivial to reproduce.
Created attachment 14502 [details]
OSX SMB server behavior when file with lease set on AFP_Resource is renamed
In case of OSX server, the RH lease is broken and a Break Response is sent to the OSX client (frame 6237, 6239).
Oh, this is tricky. As a start, we should check how Windows Server behaves in this case. I guess it will fail with ACCESS_DENIED just like Samba now does.
From that we could think about adding code to fruit to let us behave like a macOS SMB server.
Windows server behaves same as OS-X server.
3210 9 10.231.5.20 10.231.5.140 SMB2 542 Create Request File: TEST\template_storyboard.psd;SetInfo Request FILE_INFO/SMB2_FILE_RENAME_INFO NewName:TEST\template_storyboard2.psd;Close Request
3211 9 10.231.5.140 10.231.5.20 SMB2 178 Break Response
After the rename is received the Windows server sends lease break to client with RH lease and allows the rename to proceed.
Created attachment 14507 [details]
Server 2016 rename
Oh, kind of didn't expect that. Is any of you guys working on a fix? I'm currently buried beneath other stuff.
I'm sorry Ralph. I didn't see your response. I'm unfortunately also swamped at the moment. Currently we're just working around the issue by not checking for open streams during renames (i.e. revert 13451).
Has there been any progress with this issue? We have seen similar behavior in the field on some Samba configurations that heavily use Mac and Mac preview in Finder.
(In reply to Nathan Palmer from comment #8)
Sorry, but I hadn't have the time to look into this.
Some more macOS environment info for this issue
I followed your steps in Comment 1 and tested with the last 4 Mac versions, leaving everything else the same, but changing the version of macOS. Here's what I found:
10.12.6 - cannot reproduce
10.13.6 - can reproduce
10.14.5 - cannot reproduce
10.15 beta (19A471t) - cannot reproduce.
It's good to know that as reported this is only a bug with High Sierra (10.13) and isn't present in other Mac major versions. Only the version of the Finder Quicklook process in High Sierra sets a RH lease on the AFP_Resource stream.
This is still an issue. Steps to reproduce:
1) have two MacOS clients
2) extract the zipped file locally and verify that afp_resource exists using "xattr -l"
3) copy to subdirectory in SMB share that has streams_xattr enabled (or some other method of storing streams).
4) On Mac 1, switch to column view in Finder and click on file (this generates a preview of it and sets an RH lease on the file), then navigate away from it.
5) On Mac 2, attempt to delete the subdirectory. The delete will fail due to the open ADS.
Created attachment 15592 [details]
sample file with afp_resource