Bug 11065 - Renaming directories with open files
Renaming directories with open files
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
unspecified
All All
: P5 major
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-01-22 08:22 UTC by Ralph Böhme
Modified: 2016-06-23 10:42 UTC (History)
8 users (show)

See Also:


Attachments
Trace showing the spec conforming behaviour of Samba (14.79 KB, application/octet-stream)
2015-01-22 08:23 UTC, Ralph Böhme
no flags Details
Trace showing behaviour of OS X 10.9 SMB server (44.12 KB, application/octet-stream)
2015-01-22 08:24 UTC, Ralph Böhme
no flags Details
Possible implementation to allow POSIX dir renames (2.58 KB, patch)
2015-01-22 09:11 UTC, Ralph Böhme
no flags Details
Rename dir with open file, smbclient to 10.9 (5.44 KB, application/octet-stream)
2015-01-23 06:56 UTC, Ralph Böhme
no flags Details
git-am fix for 4.3.next, 4.2.next. (3.82 KB, patch)
2015-11-24 23:32 UTC, Jeremy Allison
slow: review+
jra: review? (obnox)
Details
Patch for 4.2 cherry-picked from master (22.67 KB, patch)
2015-12-04 14:27 UTC, Ralph Böhme
jra: review+
Details
Patch for 4.3 cherry-picked from master (22.68 KB, patch)
2015-12-04 14:32 UTC, Ralph Böhme
jra: review+
Details
Missing patch for 4.3, cherry-picked from master (4.12 KB, patch)
2016-06-18 07:47 UTC, Ralph Böhme
jra: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Böhme 2015-01-22 08:22:12 UTC
Looks like Apple's SMB server deviates from the standard in that it
allows renames of directories with open files. As specified in [1], a
SMB server MUST deny renames of directories with open files with an
error code of STATUS_ACCESS_DENIED.

Haven't checked yet whether there are dependencies on protocol level, capabilities or something else. The basic behaviour is just that with a 10.10 -> 10.9|10 SMB2 connection, renaming directories with open files works.

Traces attached.

[1] <https://msdn.microsoft.com/en-us/library/ff469527.aspx>
Comment 1 Ralph Böhme 2015-01-22 08:23:29 UTC
Created attachment 10646 [details]
Trace showing the spec conforming behaviour of Samba
Comment 2 Ralph Böhme 2015-01-22 08:24:21 UTC
Created attachment 10647 [details]
Trace showing behaviour of OS X 10.9 SMB server
Comment 3 Ralph Böhme 2015-01-22 09:11:29 UTC
Created attachment 10648 [details]
Possible implementation to allow POSIX dir renames
Comment 4 Jeremy Allison 2015-01-22 18:57:50 UTC
As I mentioned on the list, we need to know first if this is an Apple SMB server bug, or something that should be selected if the AAPL create context or POSIX semantics are specified.
Comment 5 Ralph Böhme 2015-01-23 06:56:07 UTC
Created attachment 10652 [details]
Rename dir with open file, smbclient to 10.9

SMB2 connection without AAPL (smbclient to 10.9): server allows rename.
Comment 6 Jeremy Allison 2015-01-23 18:45:29 UTC
If it allows it on SMB2 without AAPL, that's just a server bug :-(.
Comment 7 Ralph Böhme 2015-03-04 08:15:18 UTC
Hm, according to man smb.conf "strict rename" defaults to "no", as such we shouldn't be enforcing this which contradicts smbd behaviour, at least for SMB2.
Comment 8 Jeremy Allison 2015-11-20 21:30:00 UTC
Comment on attachment 10648 [details]
Possible implementation to allow POSIX dir renames

Hate this, it's a horrible hack :-). Might be better to add a

NSTATUS VFS rename_fsp()

call which allows modification at the NTFS emulation layer.
Comment 9 Ira Cooper 2015-11-23 14:55:09 UTC
(In reply to Jeremy Allison from comment #8)

What is the right behavior here in the case of mixed clients?

With just AAPL/POSIX clients I can see the behavior of allowing the rename as being good.  But if you have a real "Windows" style client in there, might blocking the rename be right?

Just something to think on?
Comment 10 Jeremy Allison 2015-11-24 23:32:18 UTC
Created attachment 11616 [details]
git-am fix for 4.3.next, 4.2.next.

This doesn't fix the underlying Mac bug - but is part of the ultimate patchset we'll need. Cherry-picked from master.
Comment 11 Ralph Böhme 2015-11-25 05:12:53 UTC
Not assigning to Karolin as this still misses patches for the underlying issue.
Comment 12 Ralph Böhme 2015-12-04 14:27:20 UTC
Created attachment 11668 [details]
Patch for 4.2 cherry-picked from master

This one has to go on top of Jeremy's patch "git-am fix for 4.3.next, 4.2.next.".
Comment 13 Ralph Böhme 2015-12-04 14:32:14 UTC
Created attachment 11669 [details]
Patch for 4.3 cherry-picked from master

This one has to go on top of Jeremy's patch "git-am fix for 4.3.next, 4.2.next.".
Comment 14 Jeremy Allison 2015-12-04 19:09:40 UTC
Comment on attachment 11668 [details]
Patch for 4.2 cherry-picked from master

Only one quick question before I +1 this - is there any platform where sizeof(bool) != sizeof(uint8_t) ? Or any platform where this change might make an ABI difference.

I can't think of any right now, but wanted to at least ask the question.

Jeremy.
Comment 15 Jeremy Allison 2015-12-04 19:51:49 UTC
Never mind. The only one I was worried about was ARM, then I found this:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/Babfcgfc.html
Comment 16 Jeremy Allison 2015-12-04 19:52:58 UTC
Re-assigning to Karolin for inclusion in 4.2.next, 4.3.next.
Comment 17 Karolin Seeger 2015-12-17 09:59:38 UTC
(In reply to Jeremy Allison from comment #16)
Pushed to autobuild-v4[3|2]-test.
Comment 18 Karolin Seeger 2016-01-05 08:27:10 UTC
Pushed to both branches.
Closing out bug report.

Thanks!
Comment 19 Jorge Bueno 2016-03-01 11:12:08 UTC
I have debian jessie with sernet samba 4.2.8 intalled.

I have a problems that I think are similar to this:

FolderTest
   - FileTest1
   - FileTest2  

-  If I have the folder "FolderTest" selected with an OSX client and I try to delete the folder from a different OSX client, the content is deleted but not the folder because a "File in use" error. If I try again to delete the folder with empty content(that was previously deleted) the It works.

- If I have the file "FileTest1" selected with an OSX client and I try to delete the folder from a different OSX client, fails due to the error "File in use" and nothing is deleted.

- If I have the file "FileTest2" selected with an OSX client and I try to delete the folder from a different OSX client, the content is deleted but not the folder because a "File in use" error.

- If I try to replace the folder "FolderTest" with other with the same name and same content then the content in the server is deleted.

Regards,
Comment 20 Ralph Böhme 2016-06-16 16:48:50 UTC
Hm, looks like Jeremy's patch https://attachments.samba.org/attachment.cgi?id=11616 wasn't pushed to 4.2 and 4.3. What shall we do with the drunken sailor?
Comment 21 Jeremy Allison 2016-06-16 18:54:33 UTC
(In reply to Ralph Böhme from comment #20)

Push for next releases ?
Comment 22 Karolin Seeger 2016-06-17 09:06:40 UTC
(In reply to Ralph Böhme from comment #20)
Sorry, this happened by accident.
Unfortunately, the patch does not apply on current v4-3-test.
Additionally, the last 4.2 maintenance release has been shipped today. Do we need another one?
Comment 23 Ralph Böhme 2016-06-17 09:13:45 UTC
I'll prepare a patch for 4.3
Comment 24 Jeremy Allison 2016-06-17 15:58:19 UTC
Not worth another 4.2 IMHO.

Jeremy.
Comment 25 Ralph Böhme 2016-06-18 07:47:51 UTC
Created attachment 12186 [details]
Missing patch for 4.3, cherry-picked from master
Comment 26 Ralph Böhme 2016-06-18 07:48:49 UTC
(In reply to Jeremy Allison from comment #24)
I agree, this doesn't justify another 4.2 release
Comment 27 Jeremy Allison 2016-06-22 00:47:49 UTC
Reassigning to Karolin for inclusion in 4.3.next.
Comment 28 Karolin Seeger 2016-06-22 11:10:42 UTC
(In reply to Jeremy Allison from comment #27)
Pushed additional patches to autobuild-v4-3-test.
Thanks!
Comment 29 Karolin Seeger 2016-06-23 10:42:03 UTC
(In reply to Karolin Seeger from comment #28)
Pushed to v4-3-test.
Closing out bug report.

Thanks!