Automatically mounting SMB shares for individual users on EndeavourOS or Arch Linux requires creating a dedicated systemd user service. This approach ensures that network drives are mounted only when the specific user logs in, handling credentials securely and managing dependencies like network connectivity without requiring root privileges or global automounts.
Prerequisites and Package Installation
Before configuring the mount point, you must ensure the necessary utilities are installed on your system. For EndeavourOS and Arch-based distributions, the
cifs-utils package provides the tools required to mount CIFS/SMB filesystems. Install this package using the Pacman package manager:
sudo pacman -S cifs-utils
You also need a method to store your SMB credentials securely. Storing passwords in plain text within mount options is insecure. Instead, create a credentials file in your home directory with restricted permissions. Create a file named
.smbcredentials in your home directory:
nano ~/.smbcredentials
Add the following lines, replacing the placeholders with your actual username and password:
username=your_smb_username
password=your_smb_password
Set strict permissions on this file so that only you can read it. This prevents other users on the system from accessing your network credentials:
chmod 600 ~/.smbcredentials
Creating the Mount Point
Systemd user services operate within the context of the logged-in user. Therefore, the mount point directory should reside within your home directory structure. Choose a location that fits your workflow, such as
~/network/drive. Create this directory using the
mkdir command:
mkdir -p ~/network/drive
This directory will serve as the local access point for the remote SMB share. Ensure that the ownership of this directory matches your user ID to avoid permission issues when accessing files later.
Configuring the Systemd User Service
The core of this solution is a systemd user unit file. Unlike system-wide services, user units run under your UID and do not require root access. Create a new service file in the
.config/systemd/user directory within your home folder:
mkdir -p ~/.config/systemd/user
Create a file named
smb-mount.service in this directory:
nano ~/.config/systemd/user/smb-mount.service
Populate the file with the following configuration. This setup ensures the service waits for network availability and mounts the share using your stored credentials:
[Unit]
Description=Mount SMB Share for User
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/mount -t cifs //server/share /home/youruser/network/drive \
-o credentials=/home/youruser/.smbcredentials,nofail,uid=%i,gid=%i,vers=3.0
ExecStop=/usr/bin/umount /home/youruser/network/drive
[Install]
WantedBy=default.target
Several key directives are critical here. The
After=network-online.target line ensures the service does not attempt to mount before the network is fully established. The
Type=oneshot combined with
RemainAfterExit=yes tells systemd that the service is considered "active" even after the mount command finishes, allowing it to be stopped cleanly upon logout. The
uid=%i and
gid=%i parameters automatically substitute the current user's ID and group ID, ensuring file ownership is correct regardless of which user enables the service. Replace
//server/share with your actual UNC path and adjust the mount path if you chose a different directory.
Enabling and Starting the Service
Once the service file is saved, you need to reload the systemd user daemon to recognize the new unit. Use the
--user flag to interact with the user-level instance:
systemctl --user daemon-reload
Enable the service so it starts automatically when you log in. The
default.target defined in the
[Install] section typically corresponds to the graphical session login:
systemctl --user enable smb-mount.service
To test the configuration immediately without waiting for a reboot or logout, start the service manually:
systemctl --user start smb-mount.service
Check the status to verify it is active and running:
systemctl --user status smb-mount.service
If successful, you should see the drive accessible at
~/network/drive. If the service fails, check the journal logs for detailed error messages using
journalctl --user -u smb-mount.service. Common issues include incorrect network paths, invalid credentials, or network interfaces not being ready fast enough. For more complex dependency chains, consider reviewing how to handle service failures or restart policies, as outlined in our guide on
Systemd Service Failures.
Troubleshooting and Maintenance
Network mounts can sometimes become stale if the connection drops. The
nofail option in the mount options prevents boot errors if the share is unavailable, but it may leave the mount point empty. To refresh the connection, you can stop and restart the service:
systemctl --user restart smb-mount.service
If you need to modify the mount options or credentials, edit the respective files and reload the daemon again. Remember that changing the credentials file requires restarting the service for the changes to take effect. For deeper insights into variable expansion within these service files, refer to our article on
Expanding the Use of Variables in a systemd Service File.
Frequently Asked Questions
Why use a user service instead of fstab?
Using a systemd user service allows per-user credentials and mount points without requiring root access. It integrates better with the login session and handles network dependencies more dynamically than static fstab entries.
What happens if the network disconnects?
With the
nofail option, the system will not halt during boot if the share is unreachable. However, the mount point may appear empty until the service is restarted or the network stabilizes.
How do I update my SMB password?
Edit the
.smbcredentials file in your home directory to change the password. After saving, restart the systemd user service to apply the new credentials using
systemctl --user restart smb-mount.service.
Can I mount multiple shares?
Yes, you can create separate service files for each share, such as
share2.mount.service. Each service should have a unique description and target a different mount directory to avoid conflicts.
Is this method secure?
It is reasonably secure because the credentials file has restricted permissions (600) and is owned by the user. However, storing plaintext passwords always carries some risk; consider using stronger authentication methods if available on your SMB server.