SUMMARY SMB2_OP_SETINFO requests that change only the file owner (OWNER_SECURITY_INFORMATION) via vfs_acl_xattr with "acl_xattr:ignore system acls = yes" complete with NT_STATUS_OK, but the owner SID stored in the security.NTACL extended attribute is never updated. Changes to the DACL on the very same file, via the very same mechanism, are persisted correctly and immediately. The bug is 100% reproducible, independent of client (Windows Explorer and smbcacls), independent of cluster node, and independent of an smb.conf rollback to a previous known-good version. Important refinement: the owner is set correctly at file-creation time -- i.e. a newly created file ends up owned by the user who created it, both as the real POSIX owner and as reflected over SMB. The bug only affects subsequent attempts to change the owner of an already-existing file via SMB2_OP_SETINFO. This strongly suggests the initial-creation code path (where the file is created under the real, impersonated UID of the connecting user via become_user()) is unaffected, while the distinct "modify owner of an existing SD" code path exercised by a later SETINFO/OWNER_SECURITY_INFORMATION request is the one that silently no-ops. ENVIRONMENT - Samba version: 4.22.10-Debian-4.22.10+dfsg-0+deb13u2 (Debian 13 "trixie" package) - Topology: CTDB cluster, 3 nodes, clustering = yes - Backend filesystem: CephFS (mounted at /mnt/samba-root/) - Domain mode: security = ADS, member server joined to an AD domain (realm = EXAMPLE.COM) - idmap backend: sss for the domain, tdb for * - Relevant vfs objects: catia fruit streams_xattr acl_xattr shadow_copy2 Relevant smb.conf excerpt: [global] security = ADS realm = EXAMPLE.COM vfs objects = catia fruit streams_xattr acl_xattr shadow_copy2 acl_xattr:ignore system acls = yes acl_xattr:default acl style = posix map acl inherit = Yes ea support = yes kerberos method = secrets and keytab server min protocol = SMB2_10 client min protocol = SMB2_10 smb encrypt = desired clustering = yes ctdbd socket = /var/run/ctdb/ctdbd.socket [someshare] path = /mnt/samba-root/ writeable = yes force create mode = 0660 force directory mode = 2770 inherit permissions = yes Note: the bug was reproduced identically after fully reverting to a previous smb.conf revision that predates a recent config change (which added "acl_xattr:default acl style = posix", "smb encrypt = desired", "server/client min protocol", and the "force create/directory mode" lines). The presence/absence of those lines makes no difference to this bug -- "acl_xattr:ignore system acls = yes" is present, unchanged, in both revisions and appears to be the relevant setting. STEPS TO REPRODUCE 0. (Baseline, for comparison) Create a brand-new file on the share as user A. Confirm via smbcacls/Explorer and "ls -la" on the server that the owner is correctly set to user A. This step works correctly and is not part of the bug -- it's included here only to contrast with step 3 below. 1. On a share using vfs_acl_xattr with "acl_xattr:ignore system acls = yes", pick an existing file that already has a security.NTACL xattr with a full, explicit ACL (i.e. not relying on the "default ACL style" synthesis path). 2. Grant the acting AD user/group the SeTakeOwnershipPrivilege and SeRestorePrivilege Windows privileges via: net rpc rights grant "DOMAIN\SomeAdminGroup" SeTakeOwnershipPrivilege SeRestorePrivilege -S localhost -U 'DOMAIN\admin1' (Confirmed granted via "net rpc rights list accounts".) 3. Attempt to change the file owner in any of the following ways: - Windows Explorer -> Properties -> Security -> Advanced -> Owner -> Change -> select a different, validly-resolvable AD user -> OK -> Apply. - smbcacls //server/share "path/file" -U 'DOMAIN\admin1' -C 'DOMAIN\targetuser1' - smbcacls //server/share "path/file" -U 'DOMAIN\admin1' -S "OWNER:DOMAIN\targetuser1" (SDDL form) 4. Observe the server log (log level = 3 vfs:10 acl:10 smb2:10): the SMB2_OP_SETINFO request is dispatched and completes with status[NT_STATUS_OK] within roughly 200-300 microseconds, with NO vfs_acl_xattr/xattr read-or-write activity logged in between (contrast this with a concurrent DACL-only change on the same file, which does show xattr I/O and takes measurably longer). 5. Immediately re-read the ACL: smbcacls //server/share "path/file" -U 'DOMAIN\admin1' getfattr -n security.NTACL -e hex "path/file" (on the server, directly on the filesystem) 6. (Strongest reproduction) Run "inotifywait -m -e attrib,modify path/file" directly on the server, then issue an owner-only change followed by a DACL-only change (separately) from the client. The owner-only change produces no filesystem event at all; the DACL-only change does. EXPECTED RESULT The OWNER field reported by smbcacls/Explorer changes to the newly selected user, and the owner SID encoded inside the security.NTACL xattr blob reflects the new owner. ACTUAL RESULT - smbcacls/Explorer continue to report the original owner, indefinitely, across repeated attempts, across all cluster nodes, and regardless of which client tool is used. - A byte-for-byte comparison of the security.NTACL xattr (via getfattr -n security.NTACL -e hex) taken immediately before and after the owner-change attempt shows the owner SID bytes are byte-identical -- unchanged. - The same file's DACL entries in the same xattr blob DO change correctly and immediately when a DACL-only change is made through the same client tools (smbcacls -M, Explorer "Add"/"Edit" permission entries). This was directly verified: adding an explicit ACE for a test user via smbcacls/Explorer is reflected instantly in both the xattr blob and subsequent reads. - Every SETINFO call in this scenario returns NT_STATUS_OK and the calling tool (smbcacls) exits with status 0 -- no error is surfaced anywhere (client, server log, or exit code). RULED-OUT CAUSES (WITH EVIDENCE) We spent considerable effort isolating this and can rule out the following, each independently verified: 0. Root-cause localization (strongest evidence): Using "inotifywait -m -e attrib,modify" on the target file directly on the server filesystem (completely independent of Samba's own logging/debug levels), an owner-only SETINFO request produces zero filesystem events, while a DACL-only SETINFO request on the same file, through the same client tool, reliably produces ATTRIB events. This was independently confirmed a second way using the Linux kernel audit subsystem (auditctl -w <file> -p wa, followed by ausearch): an owner-only change produces no syscall entries at all against the watched file (no setxattr, no chown, nothing) -- only the audit rule's own CONFIG_CHANGE entry appears. Three independent observation layers (Samba's own SMB2/VFS debug logging, kernel filesystem-event notification, and kernel audit syscall tracing) all agree: the server does not touch the file on any level for an owner-only change, despite responding NT_STATUS_OK. This strongly suggests the code path handling an owner-only SECINFO_OWNER request is short-circuited or dropped BEFORE it ever reaches SMB_VFS_FSET_NT_ACL / the vfs_acl_xattr module -- i.e. likely in smbd core SMB2 SETINFO handling rather than in the VFS module itself. We were not able to pin down the exact function/line without live debugging access (e.g. gdb breakpoints), but this reproduction is fully protocol/log-independent and trivially repeatable. 1. Missing NT privileges -- SeTakeOwnershipPrivilege and SeRestorePrivilege are confirmed granted to the acting group via "net rpc rights list accounts". 2. idmap / SID resolution failure -- "wbinfo -n <user>", "wbinfo -S <sid>", "getent passwd", and "id" all resolve the target user consistently and correctly to the expected UID. LSA LookupNames in the "smbcacls --debuglevel=10" trace resolves the target SID successfully (NT_STATUS_OK). 3. CephFS/backend filesystem restriction on chown -- verified that a real chown(2) performed directly by root on the underlying CephFS mount, completely bypassing Samba, succeeds instantly and correctly. 4. Missing Linux capabilities on smbd -- smbd worker processes run as real root (Uid: 0 0 0 0) with the full capability set (CapEff/CapBnd = 0x1ffffffffff), so a privileged chown() is not blocked at the OS level. 5. Cluster node inconsistency / stale cache across nodes -- write and read performed against the same node (bypassing the cluster VIP) produce the same (negative) result; a DACL write/read round-trip against the same node is immediately consistent, ruling out a general cluster-propagation-delay explanation. 6. smb.conf regression from a recent config change -- reproduced identically after a full rollback to the prior smb.conf revision. 7. Client-side issue (Windows Explorer quirk) -- reproduced identically using Samba's own smbcacls client tool (-C and -S forms), ruling out anything specific to the Windows Explorer "Advanced Security Settings" dialog. 8. Wrong smbcacls syntax -- initially suspected, but confirmed "-C USERNAME" (the dedicated chown flag, per smbcacls --help) exhibits the same behavior as the SDDL "-S OWNER:..." form. ADDITIONAL OBSERVATION Toggling "acl_xattr:ignore system acls" from "yes" to "no" (smbcontrol smbd reload-config after edit) and repeating the test did NOT change the outcome -- the owner is still not persisted through this module in our testing. (We did not do an exhaustive test matrix around this setting due to the production nature of the share; happy to provide more detail if useful for triage.) POSSIBLY RELATED We came across an unrelated user report (different backend: ZFS + VirtioFS instead of CephFS + CTDB) describing ACL modification breaking after upgrading to Samba 4.22/4.23. Not confirmed to be the same root cause, but flagging in case there is a shared regression in recent acl_xattr/ACL-handling code paths around this version range. IMPACT On a share with "acl_xattr:ignore system acls = yes" (as recommended by the module's own man page for Samba-only access scenarios), file owner cannot be changed through any SMB client whatsoever, while every other part of the NT ACL (DACL) works as expected. This is confusing for administrators, since no error is ever surfaced -- the operation appears to succeed from the client's point of view. FILES / LOGS AVAILABLE ON REQUEST - smbd debug level 10 log excerpt around the SMB2_OP_SETINFO calls for both an owner-only change and a DACL-only change on the same file, for direct comparison. - Hex dump of security.NTACL before/after an owner-change attempt. - Full (redacted) smb.conf, both current and previous revision. (Prepared with the help of an AI assistant based on troubleshooting session logs; happy to provide any further diagnostic detail needed for triage.)