Restricting Writing Access on a Samba Server: A User's Guide

To restrict writing access on a Samba server, you must configure the read only parameter within your share definitions in /etc/samba/smb.conf. Setting this directive to yes ensures that all clients can read files but cannot modify, delete, or create new content. This approach provides a simple, effective layer of security for public directories where data integrity is critical and write permissions are unnecessary for most users.

Understanding Read-Only Shares

Samba allows administrators to define granular access controls for shared resources. The primary mechanism for preventing modifications is the read only option. When enabled, the server treats the share as immutable from the perspective of network clients. This is distinct from file system permissions; even if the underlying Linux directory has 777 permissions, the Samba configuration takes precedence for network access. This method is ideal for distributing software updates, serving documentation, or hosting media libraries where users should not alter the source files. It prevents accidental deletions by careless users and protects against malicious changes. By enforcing read-only access at the protocol level, you reduce the attack surface and simplify permission management across different operating systems.

Configuring smb.conf

The core configuration file for Samba is located at /etc/samba/smb.conf. You will need root privileges to edit this file using a text editor such as nano or vim. Open the file and locate the specific [share_name] section you wish to protect. If the section does not exist, you must create it. Inside the share definition, add or modify the following line:

[my_public_share]
   path = /srv/samba/public
   browseable = yes
   read only = yes
   guest ok = no

The key directive here is read only = yes. This tells the Samba daemon to reject any write operations, including write, delete, rename, and mkdir. Ensure that you do not use non-standard variations like writable=no, as these may be ignored or cause parsing errors depending on the Samba version. Always use the standard read only syntax for compatibility and clarity. After saving the file, verify the syntax for errors by running:

testparm -s

If the test passes, restart the Samba service to apply the changes:

sudo systemctl restart smbd

Layering with Unix Permissions

While read only = yes handles network-level restrictions, it is best practice to align these with Unix file system permissions. This creates a defense-in-depth strategy. Even if a user bypasses Samba settings through other means, the underlying OS permissions provide a final barrier. For a read-only share, set the directory permissions to allow reading but deny writing for the relevant group or user. For example:

sudo chown -R root:root /srv/samba/public
sudo chmod 755 /srv/samba/public

This ensures that only the owner (root) can write to the directory locally. Network users connecting via Samba will still be blocked by the read only directive, but the local permissions prevent unauthorized local modifications if direct access is granted. This dual-layer approach is robust and recommended for production environments.

Handling Specific User Exceptions

Sometimes, you may need to make a share mostly read-only but allow specific administrators to write. In this case, rely on the valid users and write list directives rather than trying to manipulate the read only flag dynamically.

[secure_share]
   path = /srv/samba/secure
   read only = yes
   valid users = @admins @users
   write list = @admins

Here, read only = yes sets the default state. However, the write list directive overrides this for members of the @admins group. Users in @users can read but cannot write. This is more reliable than attempting complex conditional logic within the global scope. Always ensure that the Unix groups match the Samba group names defined in /etc/group.

Verifying Access Control

After applying your configuration, test the access from a client machine. On a Linux client, you can mount the share and attempt to create a file:

touch /mnt/samba/test_file.txt

You should receive a "Permission denied" error. If the operation succeeds, review your smb.conf for syntax errors or check if another configuration file is overriding your settings. Additionally, monitor the Samba logs at /var/log/samba/log.smbd for detailed information about rejected connections. For related insights on managing Linux services and configurations, see Preserve Order of Closing Services While Shutting Down Linux. Understanding service dependencies helps when restarting Samba during maintenance windows.

Frequently Asked Questions

Can I override read-only access using sudo?

No, read only = yes applies to the Samba daemon's handling of SMB/CIFS requests regardless of the user's local privileges. Even if a user has sudo rights on their local machine, they cannot write to the share unless the Samba configuration explicitly permits it via write list.

What happens if I mix read-only and writable shares?

Samba handles multiple shares independently. You can have one share configured with read only = yes and another with read only = no in the same smb.conf file. Each share operates based on its own section definitions, allowing flexible access control strategies.

Does read-only affect symbolic links?

Yes, clients cannot modify the target of a symbolic link within a read-only share. They also cannot create new symbolic links if the share is strictly read-only. This prevents potential symlink attacks where users might try to redirect writes to sensitive system directories.

How do I troubleshoot persistent write access?

Check for conflicting directives in the global section of smb.conf. If read only = no is set globally, it might override share-specific settings unless explicitly overridden. Use testparm to see the effective configuration and ensure your share section comes after any global defaults.

Is there a performance impact of read-only shares?

There is negligible performance impact. The Samba daemon simply checks the access control list for write operations and rejects them immediately. This check is lightweight and does not involve additional disk I/O or processing overhead compared to writable shares.