Group Members Can Delete Each Other's Files
A Samba 4.20 member server hosts a share for an engineering team: [engineering] path = /srv/engineering, read only = no, valid users = @eng, force group = eng, create mask = 0660, directory mask = 2770, and inherit permissions = yes. /srv/engineering is on XFS, owned root:eng, mode 2770. No acl_xattr VFS module is configured; POSIX modes are authoritative. Windows 11 clients map the share, and users in AD group ENG authenticate through winbind. The team wants members to collaborate on files, but only the file's creator should be able to delete or rename it. Currently any ENG member can delete another member's file from Windows Explorer. Files are owned by the creating user and group eng, mode 0660. New subdirectories are group-writable and inherit the setgid bit. The administrator has tried read only = no and force group = eng, but deletion behavior is unchanged. No filesystem ACLs beyond POSIX mode are in use.
1. Explain why any ENG member can delete a file owned by another member even though the file mode is 0660.
Read the worked answer
Deleting or renaming a file is not controlled by the file's own mode; it is controlled by write and execute permission on the containing directory. /srv/engineering is mode 2770, so group eng has rwx. Any ENG member can therefore unlink or rename any entry in that directory, regardless of whether the file is 0660 and owned by someone else. force group = eng only affects group ownership of new files. inherit permissions and the setgid bit propagate group and mode bits to new objects, but they do not restrict deletion. This is standard POSIX semantics, and Samba enforces it when no Windows ACL VFS module overrides it.
2. What change enforces creator-only deletion while preserving group collaboration, and what are the caveats for existing files and subdirectories?
Read the worked answer
Set the sticky bit on shared directories so only the file owner, the directory owner, or root may delete or rename entries. For the existing tree: find /srv/engineering -type d -exec chmod 3770 {} + gives setgid plus sticky; keep files at 0660. Add force directory mode = 1000 to the share so Samba ORs the sticky bit into newly created directories, or create directories with the sticky bit already set and rely on inheritance where available. Caveats: sticky prevents delete and rename, not content modification. Because files are group-writable, another ENG member can still open and truncate a file. If the requirement includes preventing edits, change files to 0640 or use ACLs. The sticky bit is a POSIX concept; do not enable acl_xattr and expect Windows ACLs to preserve it without testing. Existing subdirectories need the chmod; new ones need the Samba force mode.
3. How would you test the result from Linux and Windows, and what would you check if deletion is still allowed?
Read the worked answer
From Linux, as alice create /srv/engineering/alice.txt; as bob run rm /srv/engineering/alice.txt and expect Operation not permitted. Check ls -ld /srv/engineering for the t bit and namei -l for each parent. From Windows, map the share as alice, create a file, then map as bob and attempt delete or rename; expect access denied. Use smbclient //server/engineering -U bob and del alice.txt to isolate Samba from Explorer. If deletion still succeeds, check whether the file is in a subdirectory without the sticky bit; bob is the directory owner or root; an acl_xattr or Windows ACL is active and overriding POSIX mode; force directory mode is not applied; or inherit permissions recreated the directory without sticky. Raise log level = 3 and inspect the share path and effective mode.