[Samba] Samba stat() returning POSIX mode bits when NT ACLs are authoritative

[Ralph Boehme]

Hi!

This sounds like "acl_xattr:ignore system acls = yes" is probably what 
you're looking for.

Note that when enabling this on existing data, you have to wipe existing 
POSIX ACLs and set the mode to 0777/0666 for everything. For new files 
and dirs this happens automatically.

-slow

-- 
Join us for the 25th sambaXP 2026 conference
April 20th & 21th, 2026 at Hotel Freizeit In
sponsored by TranquilIT & Microsoft & SerNet
Ticketing & more Info at https://sambaxp.org

SerNet Samba Team Lead  https://sernet.de/
Samba Team PLC          https://samba.org/
Support and Development https://samba.plus/services/
SAMBA+ packages         https://samba.plus/products/samba

On 1/25/26 12:04 PM, Itfix via samba wrote:
> Hello Samba Team,
> 
> I would like to start a discussion about Samba’s POSIX stat semantics when NT ACLs are authoritative, and a class of issues this causes with Linux-based SMB consumers that perform POSIX pre-checks.
> 
> This is not about POSIX ACL mapping.
> 
> ### Problem statement
> 
> When Samba exports a filesystem that has real POSIX mode bits, it always returns those bits via SMB stat/query_info calls, even when access control is fully governed by NT ACLs (e.g. using vfs_acl_xattr).
> 
> Windows SMB servers, by contrast, do not expose POSIX metadata at all. Linux SMB clients (and SMB-to-VFS translation layers) therefore synthesize permissive mode bits (typically 0777), and rely on server-side ACL evaluation for the actual access decision.
> 
> With Samba, Linux-based consumers see the real POSIX mode bits and enforce them locally before any SMB write request is issued.
> 
> This causes write failures even though the NT ACL allows the operation.
> 
> ### Affected clients / scenarios
> 
> This can be reproduced with any Linux component that performs POSIX permission pre-checks based on stat():
> 
> * VMware HGFS (Linux guest → Windows host → Samba share)
> * WSL file access via Windows SMB redirector
> * FUSE-based SMB consumers
> * Any non-CIFS Linux VFS bridge layered on top of SMB
> 
> In all these cases, the write request never reaches Samba because Linux blocks it based on st_mode.
> 
> ### Why existing configuration options do not solve this
> 
> * Disabling POSIX ACLs or using vfs_acl_xattr does not affect st_mode
> * unix extensions = no disables POSIX operations, but does not prevent mode bits from being returned
> * create mask / directory mask only apply at object creation time
> * force create mode / force directory mode are workarounds, but globally falsify POSIX permissions and are not equivalent to Windows server behavior
> 
> ### Observed difference to Windows SMB servers
> 
> Windows SMB servers do not provide real POSIX mode bits. Linux clients therefore synthesize permissive permissions (typically rwx for user/group/other) and rely exclusively on NT ACLs for access control.
> 
> Samba, having real POSIX inodes, exposes restrictive mode bits that Windows servers never expose, leading to behavioral differences that cannot be resolved client-side in translation layers like HGFS.
> 
> ### Feature idea (discussion)
> 
> Would it be feasible to add an opt-in mode where Samba returns synthetic POSIX mode bits (e.g. 0777) to SMB clients when NT ACLs are authoritative?
> 
> Important properties:
> 
> * Display-only / stat-level behavior
> * No change to on-disk permissions
> * No impact on actual access control (NT ACLs still decide)
> * Share- or global-level opt-in
> 
> This would allow Samba to emulate Windows SMB server semantics more closely in mixed environments without relying on force mode workarounds.
> 
> I am aware this is a semantic change, which is why I’m raising it for discussion rather than proposing a patch outright.
> 
> Thank you for your time, and I’m happy to provide a minimal reproduction scenario if helpful.
> Best regards
> Itifix

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba/attachments/20260126/75ea2fce/OpenPGP_signature.sig>