Bug 13634 - OSX High Sierra Clients unable to rename files with AFP_Resource xattr
Summary: OSX High Sierra Clients unable to rename files with AFP_Resource xattr
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.8.4
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Ralph Böhme
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-27 22:47 UTC by Andrew Walker
Modified: 2021-04-26 22:05 UTC (History)
6 users (show)

See Also:


Attachments
OSX SMB server behavior when file with lease set on AFP_Resource is renamed (3.61 MB, application/gzip)
2018-09-28 21:00 UTC, Andrew Walker
no flags Details
Server 2016 rename (3.77 MB, application/vnd.tcpdump.pcap)
2018-10-01 22:15 UTC, Andrew Walker
no flags Details
sample file with afp_resource (1.74 MB, application/zip)
2019-10-31 13:15 UTC, Andrew Walker
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Walker 2018-09-27 22:47:55 UTC
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:

Locked files:
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.
Comment 1 Andrew Walker 2018-09-28 21:00:06 UTC
Created attachment 14502 [details]
OSX SMB server behavior when file with lease set on AFP_Resource is renamed
Comment 2 Andrew Walker 2018-09-28 21:01:24 UTC
In case of OSX server, the RH lease is broken and a Break Response is sent to the OSX client (frame 6237, 6239).
Comment 3 Ralph Böhme 2018-09-30 11:46:04 UTC
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.
Comment 4 Andrew Walker 2018-10-01 22:15:28 UTC
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.
Comment 5 Andrew Walker 2018-10-01 22:15:48 UTC
Created attachment 14507 [details]
Server 2016 rename
Comment 6 Ralph Böhme 2018-10-02 08:27:55 UTC
Oh, kind of didn't expect that. Is any of you guys working on a fix? I'm currently buried beneath other stuff.
Comment 7 Andrew Walker 2018-11-01 01:29:29 UTC
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).
Comment 8 Nathan Palmer (dead mail address) 2019-04-15 20:35:26 UTC
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.
Comment 9 Ralph Böhme 2019-04-16 04:44:15 UTC
(In reply to Nathan Palmer from comment #8)
Sorry, but I hadn't have the time to look into this.
Comment 10 Coan Dillahunty 2019-07-03 22:15:09 UTC
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.
Comment 11 Andrew Walker 2019-10-31 13:14:43 UTC
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.
Comment 12 Andrew Walker 2019-10-31 13:15:36 UTC
Created attachment 15592 [details]
sample file with afp_resource