1. Introduction
To use a given filesystem in Linux, an administrator has to first mount it. When it comes to network filesystems in particular, once operations with them are complete, it’s good practice to unmount.
In this tutorial, we briefly check how to force a Common Internet File System (CIFS) or Samba filesystem to unmount. First, we explain some basic concepts around CIFS and Samba. Next, we look at usage issues of the protocols, including a scenario in which the server is unreachable. Finally, we discuss how to deal with the latter when trying to unmount a CIFS or Samba share.
We tested the code in this tutorial on Debian 11 (Bullseye) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments.
2. CIFS and Samba
The Server Message Block (SMB) is a client-server protocol for sharing files, printers, and other resources on a given network. In addition, SMB supports inter-process communication (IPC) and authentication.
Since SMB is only a protocol, developers are free to implement it to fit their needs. In the case of Microsoft, the implementation is CIFS. Actually, CIFS has made SMB much more prevalent in Windows networks as compared to Linux.
Hence, the Linux world mostly uses its open-source Samba suite SMB implementation for interoperability with Windows environments. Due to their common base, we use SMB as an umbrella term for CIFS, Samba, and other SMB implementations.
To use SMB in Linux, we need two things:
- Install the cifs-utils or similar package
- Locate and mount an SMB share via the mount command
Let’s see a typical mount command line for a CIFS share:
$ mount -t cifs //192.168.1.1/WindowsShare /mnt/cifs_share -o username=user1,password=password123
Here, we mount the Windows share //192.168.1.1/WindowsShare on /mnt/cifs_share with the provided credentials to the local /mnt/cifs_share mount point. Due to its nature, the SMB protocol can sometimes cause problems. Let’s look at the main ones.
3. SMB Usage Issues
Protocols attempt to cover as many scenarios as possible. However, a protocol can’t plan for everything. While implementations aim to fill some holes in the original specifications based on their use case, no software is infallible.
In practice, Samba provides troubleshooting guidelines, but even these are already outdated. Still, the main problem categories are:
- incorrect configuration
- high latencies
- misconfigured or invalid authentication
- connection issues
Even with a correct configuration and proper credentials, due to the peculiarities of the protocol, we might end up with a situation where there are unexpected delays. Let’s see why.
4. Unreachable SMB Server
By default, clients wait for a given timeout period while a server receives, works on, and responds to their request. This mechanism can avoid connectivity problems on slow links, with slow systems, or during peak traffic.
On the other hand, it can severely hinder communication when the server is offline, regardless of whether it’s turned off or just out of our network’s reach. In fact, in such circumstances, we might need to wait minutes until we get an error for:
- operations on stale file handles
- a simple directory listing that involves even a single link to an SMB share file
- most SMB protocol operations
Basically, any activity that attempts to communicate with the unreachable server can end up hanging. Because of this, we often resort to disconnecting the share. However, even share unmounts can cause a hang in this situation. Considering this, what are our options?
5. Unmount SMB Server Share
Let’s use the following as an example:
$ mount -t cifs //192.168.66.60/SharedCIFS /mnt/smb
Normally, to unmount, we just use the umount command. However, attempting to directly apply that solution with an unresponsive remote server might cause a stall:
$ umount /mnt/smb
[...]
In fact, the process can hang. As with any unwanted or stalled process, we should be able to kill it:
$ killall umount
To prevent umount from hanging and get rid of the mount itself, we can force (-f) a lazy (-l) unmount:
$ umount -f -l /mnt/smb
Depending on the mount options, this might work.
Importantly, there is another common reason for the inability to unmount – open handles to files within the mount. If we use umount forcefully and lazily, it’s the system that has to clean those up. To avoid this, we can use fuser command beforehand:
$ fuser /mnt/smb
/mnt/smb: 9c 260c
Of course, if the reason for umount hanging is, in fact, an unreachable server, a command like fuser would likely also hang. Further, even if we don’t attempt to locate them, we don’t expect references to a mounted but disconnected share to remain long after any kind of umount.
Finally, if none of the above solutions work, we can always work around the issue via a reboot. Even if the system attempts to automatically remount the CIFS share, it would fail.
6. Summary
In this article, we discussed forcefully unmounting an SMB connection when it’s not responding.
In conclusion, even in situations with flawed protocols or mount dynamics, Linux provides means to handle the situation.