Duplicate Share Definition Silently Overrides the Samba Config

smb.conf is parsed top to bottom and include is a textual expansion at the point where it appears, with globs expanded in alphabetical order. When the same section name appears a second time, Samba does not create a second share: the parameters are merged into the existing service, and for any parameter given twice the last value read wins. So a leftover file matched by /etc/samba/conf.d/*.conf that redefines [projects] with read only = yes silently overrides the read only = no earlier in the main file. Nothing is logged at level 1 because the resulting configuration is perfectly valid - it is simply not what the author of smb.conf intended.

How to pin it down:

1. testparm -s prints the merged effective configuration; look at the [projects] block and note read only = Yes or a different valid users.
2. grep -rn '\[projects\]' /etc/samba/ lists every definition, and grep -rn include /etc/samba/smb.conf shows where the glob is expanded.
3. testparm -v shows defaults as well, so you can see parameters nobody set explicitly.

Fix by deleting or renaming the stale file (for example to 90-legacy.conf.disabled, which the glob no longer matches), or by removing only its duplicate section. Re-run testparm -s to confirm a single, correct definition, then systemctl reload smb - a reload affects new connections while existing sessions keep their old parameters, so have alice reconnect before retesting. Then repeat the smbclient ... -c 'put /etc/hostname test.txt' check.

Two different mechanisms are at work and they are easy to confuse. create mask / directory mask are ANDed with the permissions the client asks for - they can only remove bits. force create mode / force directory mode are ORed in afterwards - they add bits regardless of what the client requested. A create mask = 0660 therefore does not produce group-writable files when the Windows client requests 0644: the AND yields 0640 and the group write bit is gone.

For a shared group directory, set on the [projects] share:

create mask = 0660
force create mode = 0660
directory mask = 2770
force directory mode = 2770
force group = devs

The 2 in 2770 sets the setgid bit so new subdirectories inherit the devs group. If you would rather have everything mirror the parent directory, inherit permissions = yes is the alternative: it takes mode and group from the parent and makes the mask parameters irrelevant - do not mix the two approaches without deciding which one owns the policy.

Expect files to sometimes show 0740 or 0770 rather than 0660. That is map archive = yes (the default), which maps the DOS archive attribute onto the owner execute bit. store dos attributes = yes turns that mapping off and is the usual choice for POSIX-consistent permissions. The Linux umask is not involved for share files, because Samba applies these masks itself.

Verify with smbclient //localhost/projects -U alice -c 'put /etc/hostname t.txt', then getfacl /srv/projects/t.txt as root, and have a second member of devs edit the file.

Since the parent works and one subtree does not, the difference is almost certainly metadata on that subtree rather than share configuration.

1. SELinux label. ls -Zd /srv/projects/problemdir should show samba_share_t. A directory created from an unpacked tarball, an rsync run as root, or a copy from /home commonly inherits default_t, user_home_t or admin_home_t. semanage fcontext rules only apply when a relabel runs, so restorecon -Rv /srv/projects fixes it. Confirm the denial with ausearch -m AVC -ts recent or journalctl -t setroubleshoot; an AVC naming smbd and that path settles it.
2. POSIX ACL mask. getfacl on the directory shows an effective mask:: line; if a default ACL was applied to the subtree, the mask can strip group write even though the group entry says rwx. Fix with setfacl -m m::rwx or by removing the stray default ACL.
3. Ownership and mode. A subdirectory owned by root with mode 0755 blocks writes for everyone in devs regardless of Samba settings; compare stat output against the working parent.
4. Whether the client is still on an old session. smbstatus shows the connection's share parameters; a session opened before the reload keeps the old ones, so have the user disconnect and remap.

Also check mount options for a bind mount under the share, and whether the subtree is on a filesystem mounted ro. Fix the label or ACL, relabel, and retest with smbclient before telling the user.