How to Mount a Windows Share on Linux Using CIFS

When you need to access files from a Windows machine, NAS device, or Samba server, you can mount the shared folder directly into the Linux directory tree. After the mount is active, the remote files appear under a local path such as /mnt/win_share.

On Linux, Windows and SMB shares are commonly mounted with the cifs file system type through the mount command. The helper program is mount.cifs, which is installed by the cifs-utils package.

This guide explains how to install the required packages, mount Windows shares manually, use a credentials file, set permissions, create an automatic /etc/fstab mount, and troubleshoot common CIFS errors.

Quick Reference #

For a printable quick reference, see the mount cheatsheet .

Installing CIFS Utilities #

To mount a Windows share on a Linux system, you need the cifs-utils package installed.

On Ubuntu, Debian, and derivatives:

sudo apt update
sudo apt install cifs-utils

On Fedora, RHEL, and derivatives:

sudo dnf install cifs-utils

Mounting a CIFS Windows Share #

The basic syntax for mounting a CIFS share is:

mount -t cifs -o OPTIONS //SERVER/SHARE /mount/point

Mounting a remote Windows share is similar to mounting regular file systems.

First, create a directory to serve as the mount point for the remote Windows share:

sudo mkdir /mnt/win_share

Run the following command as root or a user with sudo privileges to mount the share:

sudo mount -t cifs -o username=<win_share_user> //WIN_SHARE_IP/<share_name> /mnt/win_share

You will be prompted to enter the password:

Password for <win_share_user>@//WIN_SHARE_IP/<share_name>:

On success, no output is produced.

To verify that the remote Windows share is successfully mounted, use df -h :

df -h /mnt/win_share

You can also use findmnt to show the source, target, file system type, and active mount options:

findmnt /mnt/win_share

Once the share is mounted, the mount point becomes the root directory of the mounted file system. You can work with the remote files as if they were local files.

Specifying the Password on the Command Line #

The password can also be provided directly on the command line:

sudo mount -t cifs -o username=<win_share_user>,password=<win_share_password> //WIN_SHARE_IP/<share_name> /mnt/win_share

This approach is less secure because the password is visible in the process list and shell history.

Specifying a Domain #

If the user is in a Windows workgroup or domain, you can set it with the domain option:

sudo mount -t cifs -o username=<win_share_user>,domain=<win_domain> //WIN_SHARE_IP/<share_name> /mnt/win_share

Using a Credentials File #

For better security, it is recommended to use a credentials file instead of passing the username and password on the command line.

Create a file at /etc/win-credentials with the following format:

username=user
password=password
domain=domain

The domain line is optional. Use it when the account belongs to a Windows domain or workgroup. Do not add spaces around the = signs.

The file must not be readable by other users. To set the correct permissions and ownership , run:

sudo chown root: /etc/win-credentials
sudo chmod 600 /etc/win-credentials

To use the credentials file when mounting, specify it with the credentials option:

sudo mount -t cifs -o credentials=/etc/win-credentials //WIN_SHARE_IP/<share_name> /mnt/win_share

Setting Permissions and Ownership #

When the SMB server does not provide Unix ownership information, files and directories usually appear as owned by root on the Linux client. Use uid and gid to map the mounted files to a local user and group.

First, check your user’s UID and GID:

id

The output looks similar to this:

uid=1000(linuxize) gid=1000(linuxize) groups=1000(linuxize),27(sudo)

In this example, both the UID and GID are 1000.

To mount the share as that user, pass the values with the uid and gid options:

sudo mount -t cifs -o credentials=/etc/win-credentials,uid=1000,gid=1000 //WIN_SHARE_IP/<share_name> /mnt/win_share

By default, the client shows both files and directories with mode 0755, so every file on the share looks executable. Use file_mode to set file permissions and dir_mode to set directory permissions. The following command keeps directories at 0755 and removes the execute bit from files:

sudo mount -t cifs -o credentials=/etc/win-credentials,uid=1000,gid=1000,file_mode=0644,dir_mode=0755 //WIN_SHARE_IP/<share_name> /mnt/win_share

These options control how ownership and mode bits appear on the Linux client. The server still enforces its own share permissions and Windows ACLs, so uid, gid, file_mode, and dir_mode cannot grant access that the Windows or Samba server denies.

To set additional mount options , add them as a comma-separated list after the -o option. Run man mount.cifs in your terminal for a full list of CIFS-specific options.

Specifying the SMB Protocol Version #

Modern Linux kernels auto-negotiate the highest SMB2 or SMB3 protocol version supported by both the client and server. In most cases, you do not need to specify the version manually.

If you are connecting to an older NAS device or Samba server that requires a specific protocol version, use the vers option:

sudo mount -t cifs -o credentials=/etc/win-credentials,vers=3.0 //WIN_SHARE_IP/<share_name> /mnt/win_share

Common values are 3.1.1, 3.0, and 2.1. Avoid using 1.0 because SMB1 is deprecated, weaker than modern SMB versions, and disabled by default on many current systems.

Auto Mounting with fstab #

When the share is manually mounted with the mount command, it does not persist after a reboot.

The /etc/fstab file contains a list of entries that define where, how, and what file systems will be mounted on system startup.

To automatically mount a Windows share when your Linux system starts up, define the mount in the /etc/fstab file. The line must include the hostname or the IP address of the Windows PC, the share name, and the mount point on the local machine.

Open the /etc/fstab file with your text editor :

sudo nano /etc/fstab

Add the following line to the file:

//WIN_SHARE_IP/share_name  /mnt/win_share  cifs  credentials=/etc/win-credentials,uid=1000,gid=1000,file_mode=0644,dir_mode=0755,_netdev,nofail,x-systemd.automount  0  0

• credentials=/etc/win-credentials - reads the username, password, and optional domain from the protected credentials file.
• uid=1000,gid=1000 - maps files and directories to the local user and group.
• file_mode=0644,dir_mode=0755 - controls the mode bits shown on the Linux client.
• _netdev - marks the entry as a network mount. On systemd-based distributions, CIFS mounts are already ordered after the network, so this option only makes the intent explicit.
• nofail - lets the boot continue if the share is temporarily unavailable.
• x-systemd.automount - creates an automount unit on systemd-based distributions, so the share is mounted when the path is accessed.

If you are using a systemd-based distribution, reload systemd so it notices the updated fstab entry:

sudo systemctl daemon-reload

Before rebooting, test the fstab entry. If you mounted the share manually earlier, close any files on it, leave the mounted directory, and unmount it first. The mount -a command skips shares that are already mounted, so it can miss errors in the new entry:

sudo umount /mnt/win_share

Once the share is unmounted, give mount only the mount point so it reads the source and options from /etc/fstab:

sudo mount /mnt/win_share

On success, the command produces no output. Verify that the share is mounted with:

findmnt /mnt/win_share

This tests the share and its fstab mount options. On systemd-based systems, x-systemd.automount activates an automount unit at the next reboot, and accessing /mnt/win_share triggers the CIFS mount.

Unmounting a Windows Share #

The umount command detaches (unmounts) the mounted file system from the directory tree.

To detach a mounted Windows share, use the umount command followed by the directory where it has been mounted:

sudo umount /mnt/win_share

If the CIFS mount has an entry in the fstab file and you no longer need it, remove that entry.

The umount command will fail to detach the share when it is in use. To find out which processes are accessing the share, use the fuser command:

fuser -m /mnt/win_share

Once you find the processes, you can stop them with the kill command and unmount the share.

If the server is unreachable and a normal unmount hangs, use the -l (--lazy) option. It detaches the file system from the directory tree immediately and cleans up outstanding references once it is no longer busy:

sudo umount -l /mnt/win_share

Troubleshooting #

Mount fails with “bad option” or “cannot mount read-only”
The cifs-utils package is not installed. Older systems report this as bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program. Newer kernels try the mount without the helper, ignore the credentials file, and fail with a misleading error such as cannot mount //192.168.1.10/share read-only or No route to host. Install the package with sudo apt install cifs-utils (Ubuntu/Debian) or sudo dnf install cifs-utils (Fedora/RHEL).

mount error(19): No such device
The kernel does not have the CIFS module, and mount.cifs also prints cifs filesystem not supported by the system. This happens on minimal cloud images. On Rocky Linux and other RHEL-based cloud images, the module is in the kernel-modules package:

sudo dnf install kernel-modules-$(uname -r)

mount error(13): Permission denied
The username or password is incorrect. Double-check your credentials. If the Windows share requires a domain, add the domain= option.

mount error(112): Host is down
This error can occur when the connection drops or the client and server cannot agree on an SMB protocol version. The helper may print the following message even when the server supports SMB2 or SMB3:

mount error: Server abruptly closed the connection.
This can happen if the server does not support the SMB version you are trying to use.
The default SMB version recently changed from SMB1 to SMB2.1 and above. Try mounting with vers=1.0.
mount error(112): Host is down

Check that the server is reachable, the SMB service is running, and the firewall allows traffic on port 445. Run sudo dmesg for more detail, and check the server’s supported SMB versions before changing vers.

If you confirm that the server supports only SMB1, enable SMB2 or SMB3 through a firmware update or a setting in the NAS admin panel. Use vers=1.0 only as a last resort for a confirmed SMB1-only server on a trusted network.

mount error(115) or mount error(111): could not connect
The client did not reach the SMB service on the server. On current systems, you will see a message like mount error(115): could not connect to 192.168.1.10Unable to find suitable address.

Error 115 (Operation now in progress) means the server did not answer at all. The IP address may be wrong, the server may be offline, or a firewall may be dropping the traffic. Error 111 means the server is reachable but refused the connection. Check that the SMB service is running and that the firewall allows traffic on port 445.

mount error(95): Operation not supported
This error can indicate an unsupported SMB version, authentication method, or encryption requirement. Run sudo dmesg to identify which feature is unsupported.

If the log says Dialect not supported by server, a forced vers option may be incompatible, for example vers=2.1 on a server that allows only SMB3. Remove the vers option so the client negotiates the version on its own, or set a version the server supports. If the log identifies authentication or encryption instead, check that the client and server support the requested settings.

mount error(22): Invalid argument
The client could not parse one of the mount options. A common cause is a password that contains a comma. CIFS options are comma-separated, so password=pass,word breaks the option list, and doubling the comma does not escape it. Store the password in a credentials file, or leave out the password option and type it when you are prompted.

Older guides also add sec=ntlm to the options. Current kernels reject it, and the kernel log shows bad security option: ntlm. Remove the option and let the client choose the authentication method.

Share does not mount at boot (fstab)
On systemd-based systems, CIFS mounts already wait for network-online.target. The network may still not be usable at that point, for example when Wi-Fi connects only after you log in. Add x-systemd.automount to avoid boot delays and mount the share when the path is accessed. Adding nofail prevents boot failures if the share is temporarily unavailable.

Permission denied when writing to mounted share
The local mount options may not map the share to the user you expect, or the server may deny write access. Add uid=<your_uid>,gid=<your_gid>,file_mode=0644,dir_mode=0755 to the mount options, then check the Windows or Samba share permissions if writes still fail.

FAQ #

What is the difference between CIFS and SMB?
SMB (Server Message Block) is the protocol, and CIFS (Common Internet File System) is an older dialect of SMB. On Linux, the mount -t cifs command supports modern SMB versions (2.x and 3.x) despite the CIFS name.

Is mount.cifs different from mount -t cifs?
mount -t cifs calls the mount.cifs helper from the cifs-utils package. In day-to-day use, both forms mount the same type of SMB share.

Can I mount a Windows share without a password?
Yes. For guest access, use the guest option (-o guest). It tells mount.cifs not to prompt for a password. The Windows share must be configured to allow anonymous access.

How do I find the IP address of the Windows machine?
On the Windows machine, open Command Prompt and run ipconfig. The IPv4 address is what you need for the mount command.

Is CIFS mounting secure?
Modern SMB versions are much safer than SMB1, and SMB3 supports encryption when the server and client are configured for it. For additional security, use a credentials file with strict permissions (chmod 600) and avoid passing passwords on the command line.

What is the alternative to CIFS for mounting remote directories?
You can use NFS for Linux-to-Linux file sharing or SSHFS for mounting directories over SSH.

Conclusion #

If a CIFS mount works when you run it by hand but fails after a reboot, the network is usually not ready when the share is mounted. Add x-systemd.automount so the share mounts on first access, and nofail so a missing share does not stall the boot. For Linux-to-Linux shares, consider NFS instead, which carries Unix ownership natively and skips the uid/gid mapping shown here.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page