I wanted to share some thoughts and experiences about using SMB network resources on Ubuntu Desktop. For me, it’s been a mixed bag. While Ubuntu excels in many ways, working with SMB shares and printers has always been a bit of a headache. Since these features are so common in enterprise environments, I feel like they should work more seamlessly. It makes me wonder: how do you all manage? Do you avoid SMB shares entirely in your day-to-day work? And do you work in completely paperless environments, so you never have to deal with corporate printing setups?
In my experience, the overall usability of SMB shares on Linux desktops leaves a lot to be desired. GNOME does a good job making the initial connection to SMB shares straightforward, especially with its easy Kerberos setup via the Online Accounts tool. However, beyond that, the experience can quickly become frustrating. While the CIFS kernel driver can be used as an alternative, it introduces additional problems. GNOME Files doesn’t play nice with it, making it less practical for everyday use.
One major issue is network interruptions - something that frequently occurs when you’re on Wi-Fi, switching networks, connecting to or disconnecting from corporate VPNs, or suspending and resuming desktop sessions. These interruptions often cause SMB connections to hang or become completely inaccessible. Recovering from this typically requires restarting your entire session - or, in some cases, a full system reboot might be necessary. Not exactly ideal, right? Unfortunately, this issue affects both GVFS SMB and the CIFS kernel driver.
What I’ve Noticed About SMB Support in GNOME
- Network Interruptions
- SMB connections tend to hang or stop working after network interruptions.
- To get things working again, you often have to restart your session or even reboot, which is a huge disruption.
- I’ve seen this happen with both GVFS SMB and the CIFS kernel driver.
- System Suspend and Resume
- The CIFS kernel driver doesn’t handle suspend and resume well.
- Sometimes, CIFS mounts become inaccessible, and in the worst cases, they can crash your desktop session, forcing a restart.
- Mounting Challenges
- GVFS SMB mounts are tied to GNOME and don’t support automounting. Alternatives like
autofs
orsystemd
mounts provide similar functionality and can handle automounting more effectively. - The mount paths can be unpredictable, with long path names
- Long path names can cause issues with some apps. For example, it’s often not possible to select a file from an SMB share in file upload dialogs within Chrome-based browsers.
- Kerberos tickets do not always automatically renew when accessing shares, even if credentials are available in the user’s keystore. If you weren’t connected to your corporate network during login, and unable to connect to the KDC, you’ll need to manually reauthenticate through Online Accounts or by running
kinit
to obtain a new Kerberos ticket before attempting to mount the shares.
- GVFS SMB mounts are tied to GNOME and don’t support automounting. Alternatives like
- Performance Problems
- Transferring large files (say, over 100 MB) or working with directories containing lots of files can be painfully slow or even freeze up.
- I’ve found that using command-line tools like
cp
orrsync
is often the only reliable way to handle these tasks.
- Missing Features
- Unlike Windows, network shares on Linux don’t auto-refresh. The CIFS kernel driver doesn’t support notifying applications about changes, and while SAMBA’s smbclient seems to support this at the protocol level, it lacks integration for automatic updates. As a result, users are forced to manually refresh shares to see updates.
- The lack of an auto-mounting feature makes it difficult to access shares seamlessly across different apps and tools, as they are not automatically mounted when needed.
- Managing file permissions from the UI isn’t possible. While tools like
setcifsacl
andgetcifsacl
are available, they’re not integrated into GNOME and seem to work only with the CIFS driver. Having a graphical interface for these tools would significantly improve usability.
- Two SMB Systems
- There are two SMB implementations to choose from: the CIFS kernel driver and GVFS SMB. This is confusing and inconsistent.
- Each has its quirks, and it’s not always clear which one you should use.
- Printing Challenges
- Kerberos doesn’t work with SMB+CUPS printing, the functionality exists but it is broken / packaged incorrectly (Setting up printing in a SMB/Kerberos based environment is insanely complicated and requires a binary lifted from OpenSUSE: https://gitlab.au.dk/torstenn/linux_print).
- Storing NTLM credentials securely doesn’t seem to be possible, so you’re left typing them in every time you’re creating a new print job or resorting to insecure options like text files. Additionally, this appears to only work system-wide, without support for per-user credential storage.
- Even with credentials, getting SMB-based printers to work can feel impossible.