samba - Jan 2026 - Samba stat() returning POSIX mode bits when NT ACLs are authoritative

Hi!

It probably came across wrong because I wrote the following:

"The problem isn't that it's transmitting the POSIX ACL mode bits
to the Windows client."


But that's precisely the problem: I still want the POSIX-translated Windows
ACLs written to the file system on the Linux side, even if I use
"acl_xattr:ignore system acls = yes" on the share.

I simply don't want the POSIX ACLs or POSIX mode bits transmitted to the
clients via the SMB protocol, because a Windows Server doesn't do that
either, as it doesn't support it.

Then it will also be possible to access a Samba share from a Windows client with
a FUSE file system in the following configuration: VMware HGFS (Linux guest ?
Windows host ? Samba share)

And this already works with a Windows Server, since it does not transmit POSIX
mode bits and other POSIX information to an SMB client.

One solution could be another VFS module that removes all POSIX information from
the read inodes when transferring them to the SMB client, thus creating the
illusion of a real Windows server.

But I'm not a developer or programmer, so I can't say how best to solve
this. I also used AI assistance to formulate my problem appropriately in the
initial email.

However, I cannot disregard the POSIX permissions set within the file system
itself. Since several Docker containers are running on the file server, they
obtain their permissions through mapped Windows to Linux groups, which works
very well. Even though the Windows ACLs always take precedence on the share.

I'm using Samba 4.22.6 on Debian 13, with BTRFS as the file system.

I would be happy if there were a share option in the future that prevents POSIX
metadata information from being transferred to an SMB client, because that would
solve my problem here.

My AI-formulated problem description:
-----
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.
-----



Gesendet mit Proton Mail: Ein sicherer E-Mail-Dienst.

Itifix <osm347 at proton.me> schrieb am Dienstag, 27. Januar 2026 um
07:52:
> 
> 
> Hi!
> 
> It probably came across wrong because I wrote the following:
> 
> "The problem isn't that it's transmitting the POSIX ACL mode
bits to the Windows client."
> 
> 
> But that's precisely the problem: I still want the POSIX-translated
Windows ACLs written to the file system on the Linux side, even if I use
"acl_xattr:ignore system acls = yes" on the share.
> 
> I simply don't want the POSIX ACLs or POSIX mode bits transmitted to
the clients via the SMB protocol, because a Windows Server doesn't do that
either, as it doesn't support it.
> 
> Then it will also be possible to access a Samba share from a Windows client
with a FUSE file system in the following configuration: VMware HGFS (Linux guest
? Windows host ? Samba share)
> 
> And this already works with a Windows Server, since it does not transmit
POSIX mode bits and other POSIX information to an SMB client.
> 
> One solution could be another VFS module that removes all POSIX information
from the read inodes when transferring them to the SMB client, thus creating the
illusion of a real Windows server.
> 
> But I'm not a developer or programmer, so I can't say how best to
solve this. I also used AI assistance to formulate my problem appropriately in
the initial email.
> 
> However, I cannot disregard the POSIX permissions set within the file
system itself. Since several Docker containers are running on the file server,
they obtain their permissions through mapped Windows to Linux groups, which
works very well. Even though the Windows ACLs always take precedence on the
share.
> 
> I'm using Samba 4.22.6 on Debian 13, with BTRFS as the file system.
> 
> I would be happy if there were a share option in the future that prevents
POSIX metadata information from being transferred to an SMB client, because that
would solve my problem here.
> 
> My AI-formulated problem description:
> -----
> 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.
> -----
> 
> 
> Ralph Boehme slow at samba.org schrieb am Montag, 26. Januar 2026 um 15:18:
> 
> > Hi!
> > 
> > On 1/26/26 12:18 PM, Itifix wrote:
> > 
> > > Yes, you're right,
> > > 
> > > "acl_xattr:ignore system acls = yes" is active on the
share. The
> > > problem isn't that it's transmitting the POSIX ACL mode
bits to the
> > > Windows client.
> > 
> > guess then I haven't fully understood your scenario, I didn't
consider
> > server-side filesystem POSIX ACLs should be sent over the wire.
> > 
> > I was mainly reacting to these bits:
> > 
> > > 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.
> > 
> > ...which is exactly addressed by using "acl_xattr:ignore system
acls > > yes". Are you sure you've fully understood how acl_xattr
works?
> > 
> > Anyhow, end-to-end POSIX ACL support requires support in the protocol
> > and both the server and client implementation. We have thought about
> > this as part of the SMB3 POSIX Extensions, but so far neither a design
> > nor some implementation does this as it's a lot of work.
> > 
> > It's certainly possible to bend VFS to will, to some extent, and
to
> > include reasonable changes upstream. Having worked with a lot of users
> > and customers in the past on similar goals, the reality is that this
> > requires considerable skills and effort.
> > 
> > Cheers!
> > -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

My test share configurations look like this, and unfortunately it doesn't
work as you described:

[test]
path = /test
csc policy = disable
hide dot files = No
posix locking = No
read only = No
writable = yes
vfs objects = streams_xattr acl_xattr
acl_xattr:default acl style = windows
acl_xattr:ignore system acl = yes
force create mode = 0777
force directory mode = 0777
#create mask = 0777
#directory mask = 0777

and

[test]
path = /test
csc policy = disable
hide dot files = No
posix locking = No
read only = No
writable = yes
vfs objects = streams_xattr acl_xattr
acl_xattr:default acl style = windows
acl_xattr:ignore system acl = yes
#force create mode = 0777
#force directory mode = 0777
create mask = 0777
directory mask = 0777

He's still writing the POSIX ACLs for new files, just to test a possible
solution.

------
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