Mount Windows Shares Permanently from Linux

2 years ago
Admin
6 minutes

In this post, an Ubuntu server is setup to mount DFS shares even after a reboot, securely. The post weill work with just about any recent Linux distribution and it will work with different types of Windows shares, DFS and simple SMB shares.

0 . Latest updates and prerequisites.

2023.09.23 – First draft, Ubuntu 22.04 Server.

Check back for updates, if you run into trouble. Leave a comment if the post is missing some detail.

The Windows DFS system must have DNS services setup in good health, you need sudo or root access to the linux system. Additionally, a Windows domain service user is needed with the required rights. If you have no domain or intend to connect to a standalone server or NAS, create a share and have user credentials at hand for a user with at least read access.

1 . Create a mount point.

On the linux system, a mount point needs to be made for each share that will be mounted.

The mount point can be anywhere in the logical filesystem. It should be easy to remember and identify, too. In this case, the mount point will be /mnt/shares. At the console, create the folder:

sudo mkdir -p /mnt/shares

While Windows supports some non-standard characters, such as ‘$’, in the share name, this should be avoided in the mount point name.

The permissions will be applied in the mount command. The mounting is done by root, so there is nothing more to change, here.

2 . Install dependencies.

The client for SMB or CIFS protocol is in the cifs-utils package. Install this package. In the case with non-Ubuntu distributions, the package may have another name. Update the system and add the package. Some additional packages may be installed as dependencies:

sudo apt update -y && apt upgrade -y
sudo apt install cifs-utils -y

It is not necessary to restart the system, however, if many other updates have been installed as part of the update command, then a restart is, as usual, recommended.

3 . Add a local user.

The share will be mounted to /mnt/shares and the share is located on a Windows compatible server as

\\computer_or_domain_name\shares.

Create a username and group for the default share ownership on the linux system. This username should already exist on the Windows platform, have the same name (ideally but not required) and have the required rights and permissions to the Windows share:

sudo useradd -u 5000 serviceuser

In this case, I called the username serviceuser and this username exists in Windows’ Active Directory, with the required permissions to the share and the filesystem shared. You can use any UID (-u) that is free.

4 . Create a password file

Create a file for the username and password and hide it in /etc:

sudo touch /etc/creds.file
sudo chmod 0600 /etc/creds.file
sudo nano /etc/creds.file

This file consists of the username and password for the Windows share and it looks like this exactly, except with your unquoted and non-escaped password, the domain name or servername must be specified in UPPERCASE:

username=serviceuser@domain_name_or_servername
password=the_password

In some implementations of SMB, the username has to be in the format:

username=domain_name_or_servername\\username
password=the_password

Because the mounting is actually done by root, the password file is hidden to all other users.

admin@server40:/root$ cat /etc/creds.file
cat: /etc/creds.file: Permission denied

Other users just get a ‘permission denied’ message, of sorts.

5 . Automounting at boot.

Mount points must be put to the fstab file to enable automatically mount at boot (yes, there are other ways, but this way is used almost always):

sudo nano /etc/fstab

Add lines substituting values as you see fit. In the line below, the share is mounted and the username and group are forced to prevent problems with permissions later on. (It is one line in the file):

...
//domain_or_server_name/shares /mnt/shares cifs credentials=/etc/creds.file,file_mode=0755,dir_mode=0755,uid=5000,gid=5000 0 0
...

Of course, from the terminal, the domain_name or server_name must be resolvable, otherwise an entry should be added to the hosts file. In Windows, the name has a NETBIOS equivalent. Linux may not understand this, so the full domain name must be used. The mount will fail without good network practice.

Notice the UID of the user is used, as well as the permissions of the files, from the Linux server’s perspective. Of course, if the Windows share does not allow writing, for example, the mount will still be successful, but any writes will fail.

Reboot the server or reread the fstab file with ‘mount -a’ and check this share is auto mounted with the df command:

sudo mount -a
sudo df -h

Should produce something like this:

...
/dev/sda1 1014M 193M 822M 20% /boot
//domain_or_server_name/shares 320G 134G 187G 42% /mnt/shares
...

As you can see, the shares mount point is connected to the windows share. New files in the windows share are owned by the user defined in the creds.file from the Windows point of view, but owned by the UID 5000 on the linux side.

4 . Supporting this blog.

This type of content takes a lot of effort to write. Each post is drafted, researched, then tested multiple times, even a simple step or detail might take more than a few hours to go from the idea to a published blog post.

If you feel I have saved you some time, you can support me by;

  • buying me a beer through PayPal – PayPal.

© HorseFreeGlue, 2025. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited to Gund Wehsling and aardvark.systems with appropriate and specific direction to the original content.