- Red Hat Customer Portal
- Log in to Your Red Hat Account
- Red Hat Account
- Customer Portal
- Select Your Language
- How to mount Windows share on Red Hat Enterprise Linux system using CIFS?
- Environment
- Issue
- Resolution
- Root Cause
- Mounting Windows DFS Share in Red Hat v. 6.8
- 14 Replies
- Mounting and mapping shares between Windows and Linux with Samba
- More Linux resources
Red Hat Customer Portal
Log in to Your Red Hat Account
Your Red Hat account gives you access to your profile, preferences, and services, depending on your status.
If you are a new customer, register now for access to product evaluations and purchasing capabilities.
Need access to an account?
If your company has an existing Red Hat account, your organization administrator can grant you access.
Red Hat Account
Customer Portal
For your security, if you’re on a public computer and have finished using your Red Hat services, please be sure to log out.
Select Your Language
How to mount Windows share on Red Hat Enterprise Linux system using CIFS?
Environment
- Red Hat Enterprise Linux 8
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 5
Issue
- How can Windows shares be mounted on Red Hat Enterprise Linux?
Resolution
- To run the following commands, you need to install cifs-utils package which provides mount.cifs helper program. Some commands for mounting CIFS volume require the helper program to pre-process options before issuing a mount() syscall.
Windows share can be mounted on RHEL system using cifs option of mount command as :
You can specify iocharset to convert local path names to/from UTF-8 if the server uses multi byte charset:
In case your user is in windows domain then you can define the domain as follows:
By default windows share mounted with the full permission (777) in Linux. To change the default permission use the dir_mode and file_mode options to set directory and file permission.
To make the mount persistent across reboots, make the below entry to the /etc/fstab
If a username/password/domain is needed, it is best not to leave it in fstab. In order to achieve this, the previous entry can be modified like so:
and then create the file /root/.credfile, with the following content (domain might not be mandatory):
If you receive the following error when try to mount the share folder from windows machines
Please verify the permission on the folder on you windows machine and try again mount the share folder.
Root Cause
- Fore more information, please refer to MOUNT.CIFS(8) .
- Product(s)
- Red Hat Enterprise Linux
- Component
- samba
- Category
- Configure
- Tags
- cifs
- rhel
- rhel_5
- rhel_6
- rhel_7
- rhel_8
- samba
- windows
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Mounting Windows DFS Share in Red Hat v. 6.8
I’ve setup a Windows DFS environment. I’m looking to mount specific DFS shares in Red Hat v. 6.8 and up. The only article I’ve come across so far was this:
This article points out that we can mount a drive with a hostname / IP as part of the path. In Windows DFS, we are not using a hostname but rather the domain of the AD network i.e. //Company.local/Public
Has anyone had this issue before? Is it possible to mount a DFS share in Red Hat?
Thanks for your help!
The help desk software for IT. Free.
Track users’ IT needs, easily, and with only the features you need.
14 Replies
Even with DFS, you can still get to a share by using \\hostname\share
For example, you could use this:
Thanks for the follow-up. I have been able to mount directly to a Windows DFS host (DFS1.domain.local\Public) but not to the DFS namespace (Domain.local\Public) itself. Why this is important to mount to the DFS namespace instead of a host, is to prevent any downtime if DFS host goes offline.
We don’t want to have any hostnames or IPs as part of the mounting process.
Thanks for your help.
Thanks for the follow-up. I have been able to mount directly to a Windows DFS host (DFS1.domain.local\Public) but not to the DFS namespace (Domain.local\Public) itself. Why this is important to mount to the DFS namespace instead of a host, is to prevent any downtime if DFS host goes offline.
We don’t want to have any hostnames or IPs as part of the mounting process.
Thanks for your help.
Yes I understand completely. the whole reason behind DFS in the first place.
Yes, I’ve added add the appropriate configurations to the request-key.conf file:
create cifs.spnego * * /usr/sbin/cifs.upcall -c %k
create dns_resolver * * /usr/sbin/cifs.upcall %k
I’m receiving error: mount error(6): No such device or address
I know the permissions and path are correct. Any ideas?
Yes I understand completely. the whole reason behind DFS in the first place.
Yes, I’ve added add the appropriate configurations to the request-key.conf file:
create cifs.spnego * * /usr/sbin/cifs.upcall -c %k
create dns_resolver * * /usr/sbin/cifs.upcall %k
I’m receiving error: mount error(6): No such device or address
I know the permissions and path are correct. Any ideas?
No, unfortunately that’s as far as I can go with it.
If you can’t get it working you may just have to go with a hostname to get it done. Or at least a DNS alias record so if the DFS server share goes down, all you have to do is change the alias pointer on the dns server rather than fix all the mount points on your Linux servers.
I’ve found if you do too many under the hood things in Linux to get it to work with a specific Windows function, it’ll just end up breaking later anyways when something changes. like a Linux update or who knows what.
The DNS record is the backup option. I just figured someone else out there in the world is experiencing this same issue as I am.
Thank you for your help.
Is your Linux server using the domain’s DNS?
If so, you shouldn’t have any trouble resolving the DFS namespace.
Yes I understand completely. the whole reason behind DFS in the first place.
Yes, I’ve added add the appropriate configurations to the request-key.conf file:
create cifs.spnego * * /usr/sbin/cifs.upcall -c %k
create dns_resolver * * /usr/sbin/cifs.upcall %k
I’m receiving error: mount error(6): No such device or address
I know the permissions and path are correct. Any ideas?
just a stupid question maybe, but can you ping company.local? Because, it seems that you did everything right, but i see no evidence that you, like jakke mentions, use the Active Directory DNS.
Thanks for the follow-up.
Just a stupid question maybe, but can you ping company.local?
Yes, I setup the server with a static IP w/ correct DNS servers. I can ping domain.local, ping both dns servers, and pubic websites i.e. google.com.
Googling around, I’ve also seen this command with the -t option.
Yes, I have been using the -t option as part of my command.
Googling around, I’ve also seen this command with the -t option.
Yes, I have been using the -t option as part of my command.
Stupid question perhaps, but have you tried //domain.local/dfs_root/Public instead of //domain.local/Public?
If you can ping domain.local, it finds the server, it just doesn’t see the shared drive according to your error. This leads me to believe that the path is incorrect.
I meant this command: create cifs.spnego * * /usr/sbin/cifs.upcall -c %k
I’ve seen people saying to use -t instead of -c
mount -t cifs or mount.cifs is exactly the same thing
Thanks for specifying. I switched over the text to -t and restarted the server. Same errors.
Mounting and mapping shares between Windows and Linux with Samba
More Linux resources
In my previous article, Interoperability: Getting started with Samba, I covered installing and configuring Samba shares on a Linux server. The real power of Samba comes when Windows clients can communicate with Linux file servers. In this article, I will cover how you can access Samba shares from both Linux and Windows clients.
Install the Samba client packages
To access Samba share from Linux clients we need to install a few Samba client packages.
On the client machine, install the samba-common and samba-client packages.
Check for available shares
Let’s check if we can access our shares from the server. We can use either the hostname or ip address of the server. If you use the hostname , make sure DNS is working.
Create a directory that we can use as our mount point. I’m going to create a directory under /mnt , but you can use any directory you would like to. You may need to configure SELinux on that directory.
Now, mount the share.
Now that we’ve mounted our share, we can check the mounts with the following command:
Let’s make that directory mount persistently so it can withstand a reboot. Using the text editor of your choice, edit the /etc/fstab file. You can do this in multiple ways, but I’m going to demonstrate two ways to mount the Samba share at boot in /etc/fstab .
The first option provides a username and password for the Samba user in the fstab .
The other option is to create a credential file. You can call this file anything, but I would like to call it cred . I would like to place credentials files in the home directory of the user. In our demonstration it will be /home/user/.cred .
The _netdev option is important since we are mounting a network device. Clients may hang during the boot process if the system encounters any difficulties with the network.
Now create that .cred file inside the user’s home directory.
Next, add the Samba user’s username and password.
Finally, mount all filesystems.
Access a share from a Windows client
I will be using Windows 10 as my client machine with a workgroup called SAMBA . We need to create a local user account on the Windows machine that matches the username and password of the Samba user account we created in my previous article. Although account creation is not necessary, this will make things simpler when accessing the share.
Like I mentioned above, this step is optional and you can skip it completely. Although there are multiple approaches to adding a new local user on a Windows machine, for the simplicity of this article I will be using PowerShell. Launch PowerShell as an administrator and issue following commands:
Now that we have created a new local user account matching the Samba user account, we can log in to Windows with our newly created user account.
Access a share from Windows Explorer
To access the Samba share from Windows Explorer, start typing the IP address to our share in the search area. I am using the hostname of the Samba server. In my case, it is centos . You can also access the share by using the IP address of the Samba server.
You might be prompted to enter the username and password to access the share if you skipped the local user creation process. If you get prompted for credentials, enter the Samba username and password we created in the previous article.
You will need to enter the Samba share path every time you want to access the share. There is a better way to access the share by mapping a drive to Samba share in Windows.
Mapping a drive to a Samba share
To map a drive to the Samba share, open PowerShell and issue following command:
Accessing a Samba share on Linux and Windows is easy. With this basic setup, you will be able to access file shares from client machines in your network. With somewhat more configuration, you can deploy Samba shares in a domain environment. Samba can do more than file share. If you would like to learn more about Samba, read this article about Windows and Linux interoperability. This is a basic set up, but you can do so much more with Samba.
[ Want to test your sysadmin skills? Take a skills assessment today. ]