Created attachment 2145098 [details]
Proposed patch

Description of problem:

When vfs_fruit is used for macOS clients, those clients can chmod a file to 000 permissions. This is supposed to work, and the file should be capable of being changed back to a normal mode. However, this does not work, causing files to be "stuck" at 000 mode without manual admin action on the server side.

Going through 000 permissions is normal. For example, the `mv` command on macOS creates files as 000 initially, and only changes permissions later:

https://github.com/apple-oss-distributions/file_cmds/blob/659a8a301e2acf0343f8b8673a154a2ca4d07084/mv/mv.c#L400

When creating a file, macOS does a Create request followed by a SetInfo request. Since the mode is set by a separate operation, `force create mode` is ineffective and cannot be used as a workaround.

This initial chmod looks like this in the logs:
[2026/06/11 16:17:42.767618, 10, pid=111367, effective(2001, 2001), real(2001, 0), class=fruit] ../../source3/modules/vfs_fruit.c:4656
(fruit_fset_nt_acl)
  fruit_fset_nt_acl: test3
[2026/06/11 16:17:42.767634, 10, pid=111367, effective(2001, 2001), real(2001, 0), class=fruit] ../../source3/modules/vfs_fruit.c:1312
(check_ms_nfs)
  MS NFS chmod request test3, 0000

At this point, the file is mode 000.

macOS then logically closes the file at the SMB level, then re-opens it to chmod it again. However, the file can no longer be opened:

[2026/06/11 16:17:43.059169, 10, pid=111367, effective(2001, 2001), real(2001, 0)] ../../source3/smbd/open.c:186(smbd_check_access_rights_sd)
  smbd_check_access_rights_sd: File [test3] requesting [0x160080] returning [0x100000] (NT_STATUS_ACCESS_DENIED)

macOS requests access mask 0x160080 when opening the file again. These bits are:

- FILE_READ_ATTRIBUTES
- READ_CONTROL_ACCESS
- WRITE_DAC_ACCESS
- SYNCHRONIZE_ACCESS

Although the file is mode 000 (indicating no access), some implicit permissions are granted: 

FILE_READ_ATTRIBUTES here:
https://repo.or.cz/Samba.git/blob/HEAD:/source3/smbd/open.c#l294

READ_CONTROL_ACCESS and WRITE_DAC_ACCESS here:
https://repo.or.cz/Samba.git/blob/HEAD:/libcli/security/access_check.c#l577
https://repo.or.cz/Samba.git/blob/HEAD:/libcli/security/access_check.c#l439

The remaining bit, SYNCHRONIZE_ACCESS is considered missing (0x100000 in the log message), and this causes the request to return access denied.

The file is no longer accessible, as no operation from macOS can bring it back to a non-zero mode, since all open requests set SYNCHRONIZE_ACCESS.

The SMB1 spec says this about SYNCHRONIZE:

> This flag SHOULD NOT be used by the client and MUST be ignored by the server unless on a named pipe as discussed in section 3.2.4.3.1 and section 3.3.5.5.

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/27f99d29-7784-4684-b6dd-264e9025b286

While the SMB2/3 spec says:

> SMB2 clients set this flag to any value.<48>
> SMB2 servers SHOULD<49> ignore this flag.

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/77b36d0f-6016-458a-a7a0-0f4a72ae1534

Therefore, this is a spec compliance bug in Samba, and it should ignore this bit.

Proposed patch attached, which I confirmed resolves the issue.

Version-Release number of selected component (if applicable):

samba-4.23.8-1.fc43.aarch64

How reproducible:

Always

Steps to Reproduce:
1. Set up a share with vfs_fruit enabled (with fruit:nfs_aces=yes, the default)
2. Mount the share in macOS (tested Tahoe 26.5.1)
3. mv ~/some_file /Volumes/Share/

`git` also has issues, though not consistently (things like `git add` and `git commit` can fail).

Actual results:

mv: ./some_file: set mode (was: 0644): Permission denied
mv: ./some_file: set times: Permission denied
mv: ./some_file: set flags (was: 00000000): Permission denied

Expected results:

mv works.

Additional info:

I tried to report this upstream, but apparently they make you send them an email to create a Bugzilla account manually so I gave up...