Bug 13999 - macOS clients since at least 10.14 have a problem with Zero FileIDs
Summary: macOS clients since at least 10.14 have a problem with Zero FileIDs
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Ralph Böhme
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-17 13:58 UTC by Ralph Böhme
Modified: 2019-07-08 13:34 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Böhme 2019-06-17 13:58:06 UTC
Steps to reproduce with a macOS SMB server:

- Mac with 10.14.x as client

- set file_ids_off=yes in /etc/nsmb.conf on the client Mac and restart

- connect to another Mac over SMB

- run the following steps in Terminal on the client:

  $ mkdir /Volumes/name/dir/
  $ touch /Volumes/name/dir/file

- on the Mac SMB Server:

  $ rm /path/to/share/dir/file

- back on the client:

  $ touch /Volumes/name/dir/file
  -bash: file: Permission denied

This is 100% reproducable once you set file_ids_off=yes. Remove it,
problem goes away.

Nowadays Samba (when using the VFS module fruit) returns 0 file ids to
macOS clients which has the same effect and this triggers the problem
for many, many Samba servers.

See bug #12715 for an explenation on the Zero FileID semantics.
Comment 1 Ralph Böhme 2019-06-26 09:08:09 UTC
Note that the problem can also be reproduced if another SMB client removes the other client's file, instead of doing it on the server on the command line:

- macOS SMB server 10.14.6
- client A, macOS 10.14.6, file_ids_off=yes in nsmb.conf
- client B, macOS 10.14.6, file_ids_off=yes in nsmb.conf
- connect both clients
- client A: create subdirectory in share
- client A: open that subdirectory in Finder
- client A: copy file from Desktop to directory in share with Finder
- client B: navigate to directory in Finder
- client B: delete file
- on client A you'll notice the file is removed from the Finder window, FCN and  Directory Lease breaks are sent out from the server
- client A: try again to copy file from Desktop to directory in share with  Finder, this time this fails with a Finder error winndow stating the file  already exists
Comment 2 Coan Dillahunty 2019-06-28 22:34:10 UTC
Some more macOS environment info along with tests:

I followed your steps in Comment 1 and tested with the last 3 Mac versions, leaving everything else the same, but changing the version of macOS for client A. Here's what I found:

10.14.5 - can reproduce
10.13.6 - can reproduce
10.12.6 - cannot reproduce

So this issue predates macOS Mojave and is reproducible on at least the latest version of High Sierra (10.13.6). Sierra (10.12.6) didn't have this problem.
Comment 3 Coan Dillahunty 2019-06-28 22:42:26 UTC
Just tested with the macOS 10.15 Catalina beta (19A471t) and it has the same problems as Mojave and High Sierra when file_ids_off=yes is set.
Comment 4 Ralph Böhme 2019-07-08 13:34:42 UTC
Fixed in master. Next release shipping the fixes will be 4.11.

There will be no backports for older versions as this breaks the VFS ABI.