Mount a Windows Share on Linux with CIFS (RHEL, Rocky, Ubuntu)

Mounting a Windows share on Linux is a common task in mixed Windows and Linux environments. Whether you are moving files between systems, giving an application access to a shared folder, or standardizing storage access across servers, the usual approach is to mount the Windows shared folder on Linux using the SMB/CIFS protocol and the cifs-utils package.

In this guide, you will learn how to mount a Windows share on Linux on RHEL, Rocky Linux, and Ubuntu. We will cover both a one-time manual mount and a persistent mount using /etc/fstab, along with security best practices, SELinux notes, AppArmor considerations, and troubleshooting common errors such as permission denied and SMB version mismatches.

If you are working with Linux-based network shares instead of Windows shares, read our guide on how to mount an NFS share on Linux.

Before you begin

For security and privacy, this article uses generic placeholders instead of real infrastructure details. Replace the following values with your own:

<windows-host> = the Windows hostname or IP address
<share-name> = the shared folder name on Windows
<mount-point> = the local Linux directory where the share will be mounted
<username> = the Windows account used to access the share
<password> = the password for that account
<domain> = your Windows domain or workgroup if needed

On the Windows side, make sure the folder is shared and that the account you plan to use from Linux has permission to access the share. In many environments, the account also needs the correct share permissions and NTFS permissions before the mount will work as expected.

Mount a Windows SMB/CIFS share on Linux using cifs-utils, a credentials file, and a local mount point.

Install cifs-utils

The cifs-utils package provides the tools Linux uses to mount SMB and CIFS shares. Red Hat documentation lists cifs-utils as the package needed for mounting SMB shares on RHEL-family systems, and the official mount.cifs manual documents the helper used for the mount operation. Ubuntu’s current server documentation also uses CIFS terminology for permanent mounts. :contentReference[oaicite:1]{index=1}

Install the package with the command appropriate for your Linux distribution.

RHEL and Rocky Linux

dnf install -y cifs-utils

Ubuntu

apt update
apt install -y cifs-utils

Create a credentials file

One of the most important security recommendations is to avoid placing usernames and passwords directly on the mount command line or directly in /etc/fstab. A credentials file is cleaner and safer because it reduces exposure in shell history and process listings.

Create a credentials file such as /root/.cifs-creds:

cat > /root/.cifs-creds <<'EOF'
username=<username>
password=<password>
domain=<domain>
EOF

Then lock down the file permissions so only root can read it:

chmod 600 /root/.cifs-creds

If you are not using Active Directory or a Windows domain, you can usually omit the domain= line. In some smaller environments, the workgroup name is used instead.

Create the mount point

Create the local directory that will hold the mounted Windows share:

mkdir -p /mnt/<share-name>

You can use another location if you prefer, such as /srv/<share-name> or an application-specific path. The important part is that the directory exists before you attempt the mount.

Mount the Windows share on Linux

To mount the Windows shared folder manually, use mount -t cifs with the remote UNC path, the local mount point, and your credentials file.

mount -t cifs //<windows-host>/<share-name> /mnt/<share-name> -o credentials=/root/.cifs-creds

At this point, the share should be available under the Linux mount point. To verify the mount, run one or both of the following:

mount | grep cifs
df -h | grep /mnt/<share-name>

You can also test access directly by listing the directory contents:

ls -la /mnt/<share-name>

Example with a more complete mount command

In real-world environments, it is often helpful to specify ownership and file modes so applications and users on Linux interact with the mounted share more predictably. Here is a practical example:

mount -t cifs //<windows-host>/<share-name> /mnt/<share-name> \
  -o credentials=/root/.cifs-creds,uid=0,gid=0,file_mode=0640,dir_mode=0750

Those options are useful when you want to control how the mounted files appear on the Linux side. The uid and gid values control ownership presentation, while file_mode and dir_mode influence displayed permissions for the client mount.

Make the mount persistent with /etc/fstab

If you want the Windows share to mount automatically after reboot, add it to /etc/fstab. The fstab file is the standard Linux configuration file used to define filesystems that can be mounted at boot or on demand. :contentReference[oaicite:2]{index=2}

Add an entry like this:

//<windows-host>/<share-name> /mnt/<share-name> cifs credentials=/root/.cifs-creds,iocharset=utf8,nofail,x-systemd.automount,_netdev,uid=0,gid=0,file_mode=0640,dir_mode=0750 0 0

Several of these options are worth understanding:

credentials=/root/.cifs-creds uses the protected credentials file instead of exposing secrets directly.
iocharset=utf8 helps with file name encoding.
nofail prevents boot from failing if the share is unavailable.
x-systemd.automount can help delay the mount until access is attempted.
_netdev indicates the mount depends on networking.

After updating /etc/fstab, test the entry before rebooting:

mount -a

If there are no errors, your entry is likely valid. If there is an error, correct it now instead of discovering it after a reboot.

When to use a hostname instead of an IP address

If DNS is working reliably in your environment, using a hostname instead of a raw IP address is often the better long-term choice. Hostnames are easier to read, friendlier to documentation, and less likely to break if the server’s address changes later. However, if you are troubleshooting connectivity or do not yet trust name resolution, an IP address can be a useful temporary test.

SELinux considerations on RHEL and Rocky Linux

If the share mounts successfully but an application still cannot read or write to it, SELinux may be part of the problem. This is especially common when a web server, scheduled job, or service account is trying to access a mounted CIFS path.

Start by checking for denials:

getenforce
ausearch -m AVC -ts recent

For web server scenarios, your article on httpd and SELinux is a useful related reference.

Depending on the service and access pattern, you may need an SELinux boolean or a proper file context strategy. Do not disable SELinux as a first resort. It is usually better to determine which policy is blocking access and address that directly.

AppArmor considerations on Ubuntu

Ubuntu typically uses AppArmor rather than SELinux as its mandatory access control system. Canonical’s current server documentation explains AppArmor profiles and also documents Samba-related AppArmor profile adjustments on Ubuntu. :contentReference[oaicite:3]{index=3}

If the mount itself works but a confined application cannot access the mounted path, inspect whether the application’s AppArmor profile allows the target directory. Useful checks include:

aa-status
journalctl -xe | grep apparmor

As with SELinux, do not remove security controls unnecessarily. First confirm whether AppArmor is the reason access is being blocked, then adjust the relevant profile if needed.

Security best practices

Do not put the password directly in the shell command if you can avoid it.
Protect the credentials file with chmod 600.
Use a dedicated share account instead of a broadly privileged administrative account whenever possible.
Prefer a DNS hostname over a hard-coded IP address when your DNS is stable.
Use the least privileges needed on both the Windows share permissions and NTFS permissions.
Test the mount with mount -a after editing /etc/fstab instead of waiting for the next reboot.

Troubleshooting mount Windows share on Linux

mount error(13): Permission denied

This usually means one of the following:

the username or password is wrong
the domain or workgroup is incorrect
the Windows account lacks share or NTFS permissions
the server requires a different SMB security or version setting

Double-check the credentials file first, then confirm the account can access the share from a Windows system.

Could not resolve address or host unreachable

If you are using a hostname, verify DNS resolution and basic connectivity:

getent hosts <windows-host>
ping -c 4 <windows-host>

If needed, test once with the IP address to separate name-resolution issues from SMB issues.

Wrong SMB version or protocol negotiation problem

Some older servers and some hardened environments require explicitly setting the SMB version. If negotiation is failing, try specifying the version manually.

mount -t cifs //<windows-host>/<share-name> /mnt/<share-name> \
  -o credentials=/root/.cifs-creds,vers=3.0

Other environments may require a different value such as vers=2.1 or vers=3.1.1. The official mount.cifs documentation is the right place to review supported options. :contentReference[oaicite:4]{index=4}

The credentials file is being ignored

Make sure the credentials file path is correct, the permissions are restrictive, and the file contents are formatted exactly as expected:

username=<username>
password=<password>
domain=<domain>

Watch out for extra spaces, Windows line endings, or hidden characters introduced by editing the file in the wrong tool.

The mount works as root but not for an application

If root can read the mounted share but a service cannot, focus on Linux-side permissions and your security framework. Ownership options like uid, gid, file_mode, and dir_mode may need adjustment, and SELinux or AppArmor could also be blocking access.

Frequently asked questions

How do I mount a Windows share on Linux?

Install cifs-utils, create a credentials file, create a mount point, and run mount -t cifs against the Windows share path. For a persistent mount, add the share to /etc/fstab.

What package do I need to mount an SMB or CIFS share on Linux?

You need the cifs-utils package. This is the standard package used on RHEL-family systems and Ubuntu for mounting SMB/CIFS shares. :contentReference[oaicite:5]{index=5}

Should I use SMB or CIFS terminology?

Both terms appear in Linux documentation and search queries. In practice, Linux mount commands often use -t cifs, while administrators often describe the same task as mounting an SMB share on Linux.

How do I make a Windows share mount automatically on Linux?

Add the mount to /etc/fstab using a credentials file and test it with mount -a. Options like _netdev, nofail, and x-systemd.automount are often helpful for network shares.

Why does my CIFS mount return permission denied?

The most common causes are incorrect credentials, incorrect domain information, missing Windows permissions, or an SMB negotiation issue. Start by validating the account and share permissions, then test the mount again with a known-good credentials file.

Can SELinux or AppArmor block access to a mounted Windows share?

Yes. Even when the mount succeeds, a confined service or application can still be blocked by SELinux on RHEL-family systems or AppArmor on Ubuntu. Check the relevant logs and policy status if the share is mounted but inaccessible to an application. :contentReference[oaicite:6]{index=6}

Conclusion

Mounting a Windows directory on Linux is straightforward once the share permissions, credentials, and local mount options are set correctly. For most environments, the safest and cleanest approach is to install cifs-utils, store credentials in a protected file, test the mount manually, and then add the share to /etc/fstab for persistence.

If the mount works but access still fails, do not forget to check Linux-side controls such as ownership presentation, SELinux, and AppArmor. Those layers are often the missing piece when a Windows share appears mounted but an application still cannot use it.