You can temporarily disable a Samba share without restarting the server by modifying the
global or
[share] section in
/etc/samba/smb.conf. Adding the parameter
available no to the specific share definition prevents new connections while allowing existing sessions to complete. This method ensures service continuity for Linux and Windows clients without requiring a full daemon restart or system reboot.
Understanding the Available Parameter
The
smb.conf configuration file controls how Samba exports directories to network clients. Each share is defined within its own bracketed section, such as
[public] or
[documents]. By default, shares are available to any authenticated user who meets the access criteria. However, administrators often need to pause access for maintenance, security audits, or when a directory becomes corrupted.
Instead of stopping the
smbd service entirely, which disconnects all users and requires a restart to restore services, you can use the
available directive. When set to
no, Samba will reject new connection requests for that specific share. It does not forcibly kick off users who are already connected, providing a graceful degradation of service rather than an abrupt interruption. This approach is particularly useful in mixed environments where Windows clients might retry connections aggressively if the server simply drops them.
Modifying the Configuration File
To implement this change, you must edit the main Samba configuration file. On most Linux distributions, this file is located at
/etc/samba/smb.conf. You should open this file using a text editor with root privileges, such as
sudo nano /etc/samba/smb.conf or
sudo vi /etc/samba/smb.conf. Always create a backup of the original file before making changes to prevent configuration loss due to syntax errors.
Locate the section corresponding to the share you wish to disable. It will look like this:
[my_share]
path = /srv/samba/my_share
browseable = yes
read only = no
Add the line
available no anywhere within this block. The order of parameters generally does not matter, but placing it near the top of the section improves readability. The updated block should resemble the following:
[my_share]
available no
path = /srv/samba/my_share
browseable = yes
read only = no
After saving the file, you must verify the syntax to ensure there are no typos that could prevent Samba from loading the configuration. Use the command
testparm to check for errors. If
testparm reports success, your configuration is valid. If it reports errors, correct them before proceeding. This step is critical because a malformed configuration file can cause the entire Samba service to fail to start or reload.
Reloading the Samba Service
Once the configuration is saved and validated, you need to apply the changes. Samba uses a master process that reads the configuration file and spawns worker processes. To apply the new settings without killing existing connections, you should send a HUP signal to the master process or use the systemd management tool.
On modern Linux systems using systemd, the recommended command is:
sudo systemctl reload smbd
This command tells the operating system to reload the configuration files for the
smbd service. Unlike a restart, a reload does not terminate active sessions. Users who were accessing the disabled share will remain connected until they close their file explorers or unmount the drive. New connection attempts will immediately fail with a "Network Path Not Found" or similar error, depending on the client operating system.
If you are using an older system without systemd, you can send the HUP signal directly:
sudo kill -HUP $(cat /var/run/samba/smbd.pid)
This achieves the same result by forcing the master process to re-read
smb.conf.
Re-enabling the Share
To make the share available again, reverse the previous steps. Edit
/etc/samba/smb.conf and either remove the
available no line or change it to
available yes. Save the file and run
testparm to verify syntax. Finally, reload the service using
sudo systemctl reload smbd. Clients may take a few seconds to recognize that the share is back online, depending on their caching behavior.
For more information on managing Linux services, see
Troubleshooting kex_exchange_identification Error in Linux SSH Connection.
Troubleshooting Common Issues
Sometimes, clients may continue to see the share in their network neighborhood even after it has been disabled. This is usually due to browser cache or NetBIOS name resolution delays. Instruct users to refresh their network list or clear their DNS cache. On Windows, running
ipconfig /flushdns can help. On Linux clients, refreshing the Nautilus file manager or restarting
nmbd may be necessary.
If new connections still succeed despite setting
available no, check for duplicate share names. If two shares have the same name, Samba may load the first one it encounters. Ensure that the share name is unique across all sections in
smb.conf. Additionally, verify that no other configuration files in
/etc/samba/conf.d/ or included via
include directives override your changes.
Frequently Asked Questions
Does available no disconnect current users?
No, the
available no directive only affects new connection attempts. Existing sessions remain active until the client closes the connection or the session times out due to inactivity.
Can I use this method for all shares at once?
Yes, you can add
available no to every share section in
smb.conf. This effectively disables all Samba exports without stopping the daemon, which is useful during major system updates.
What happens if I restart the server instead of reloading?
A full server restart will also disable the share, but it causes a significant outage for all services running on the machine. Reloading is preferred because it maintains uptime for other applications and allows a graceful shutdown of Samba resources.
How do I verify the share is actually disabled?
You can test connectivity from another machine using
smbclient -L localhost. The disabled share should no longer appear in the list of available shares returned by the command.
Is there a risk of data corruption when disabling shares?
There is no direct risk to data integrity when using
available no. Since existing writes continue normally, files are not left in an inconsistent state. However, avoid performing disk maintenance or moving files while users are still actively writing to the share.