1. Introduction
Although almost every operating system (OS) and Linux distribution have a graphical user interface (GUI), the command-line interface (CLI) is commonly the preference in the Linux world. To that end, there are often several approaches to certain tasks, especially when they involve different protocols.
In this tutorial, we look at ways to map a network share as a drive using the CLI. First, we discuss the general terminology around mapping and mounting. Next, we show how to map a drive under Linux, simulating the GUI procedures from the CLI.
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. Mapping Drives and Mounting Shares
Networking has provided a convenient way to share and collaborate on data. However, network share interfaces, protocols, and filesystems vary among operating systems. Because of this, it’s often better to expose data in a standardized way.
Thus, Microsoft Windows has drive mapping, while the Linux world uses mounting. Essentially, they are similar in terms of their goals:
- expose remote data locally
- allow data modification and manipulation
- blur or completely remove the line between local and remote files
While Windows uses separate drive letters, mounting any filesystem on Linux just requires a mount point, which is basically any local path. Still, the way we perform the map or mount differs from OS to OS and from GUI to CLI.
Here, we discuss scenarios that involve attaching an SMB share to a Linux machine via the CLI in a manner similar to that of the GUI.
3. Map Drive Under Linux
Regardless of their common roots and aim, different Linux components may handle mapping in different ways. To show the differences, we use a Windows CIFS share: \\192.168.6.66\cifsShare.
3.1. Regular Mount
To mount a CIFS share, we’d normally need to install the appropriate tools, create a mount point, and perform the mounting with mount:
# apt-get -y install cifs-utils
[...]
# mkdir /mnt/cifs_share
# mount -t cifs //192.168.6.66/cifsShare /mnt/cifs_share
Now, we can use the /mnt/cifs_share directory and its contents just like a regular local filesystem. These steps are standard for Linux but are by no means the only way to attach a (network) filesystem seamlessly to our directory tree.
3.2. GNOME
The GNOME desktop environment is a classic. Despite being a GUI, it ships with many improvements on built-in Linux functions.
For example, the GNOME Virtual File System (GVFS) packages several backends that span different protocols and scenarios. One of them is SMB, which normally requires installing packages to mount.
To connect to a CIFS SMB share from GNOME, we can simply use the interface. Since how that is done varies by version, it’s best to refer to the appropriate user manual for the exact steps.
Importantly, native GNOME applications use the gio library and toolkit in the background of GUI operations. In fact, we can use the CLI and gio mount to replicate the way we’d mount in the GUI:
$ gio mount smb://192.168.6.66/cifsShare
Here, we specify the smb protocol as a prefix, while an interactive prompt enables us to enter credentials if necessary.
Regardless of the way we choose to map an SMB share in GNOME, it will be available in a subdirectory of $HOME/.gvfs or /run/user/UID/gvfs, where UID is the mounting user’s ID:
$ mount
[...]
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
Note the mount name suffix fuse, referencing the kernel FUSE component.
Let’s see how the same works in another common GUI.
3.3. KDE
Similar to GNOME, KDE is a desktop environment with its own supplemental packages and frameworks for different tasks and functions.
One of those packages is smb4k, which is a GUI network browser specifically targeting SMB share mounting. In fact, KDE Input Output (KIO) is a dependency of smb4k. Critically, KIO is the input and output framework used in native KDE applications.
Essentially, using smb4k still relies on cifs-utils but again has a standard mount location preconfigured: /run/user/UID/kio-fuse-*.
On the CLI side, we can turn to kioclient:
$ kioclient exec smb://192.168.6.66/cifsShare
This command opens the GUI at the share location, possibly triggering kio-fuse which automounts under the kio-fuse-* directory, similarly to GVFS and the gvfs directory.
4. Summary
In this article, we talked about drive mapping and mounting, as well as several methods to replicate or initiate the GUI mounting procedure from the CLI.
In conclusion, despite the different terminology, mounting and drive mapping are very similar, and there are many ways to perform them via the GUI and CLI.