Mike’s Technology and Finance Blog
Mike’s Technology and Finance Blog covers a number of different topics in finance and technology. Most technical posts provide architecture, development, implementation, troubleshooting techniques for different Enterprise IT systems that run on the Windows, UNIX, and Linux platforms. Some posts also include my personal opinions and rants.
Wednesday, October 3, 2012
How to Mount a DFS Share in Linux
Microsoft Distributed File System (DFS) is a technology that allows multiple servers to host a single file share (providing fault tolerance and performance enhancement for multi-site Active Directory topologies). It is typically used in conjunction with a replication technology such as DFS-R (R is for Replication). Though these features have similar names, you don’t have to have DFS to use DFS-R and vice versa (A typical use case might be the desire to replicate folders between servers, but not share them, which is accomplished via DFS-R without using a DFS namespace).
Windows clients (Windows XP SP3, Windows Vista, Windows 7, and Windows 8) and servers (Windows Server 2003 SP2, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012) mount shares in a DFS namespace seamlessly, but the same isn’t true for Mac OS (earlier than Lion). Linux systems have the capability to mount DFS, but they require some additional configuration above and beyond issuing a ‘mount’ command. In the modern versions of Linux, Windows file shares are mounted using the kernel Common Internet File System (CIFS) driver.
In order to mount a DFS volume, the following packages need to be available (these may vary per platform, but are consistent on RedHat/CentOS and SUSE):
cifs-utils (specifically mount.cifs and cifs.upcall)
keyutils
Based on testing in RedHat Enterprise Linux, samba is NOT required to mount a CIFS share hosted in a DFS namespace. A small piece of configuration is necessary to mount a DFS share on Linux. The configuration needs to be added to the keyutils configuration file (bolded below in the list of files included with the package),
/bin/keyctl
/etc/request-key.conf
/etc/request-key.d
/sbin/request-key
/usr/share/doc/keyutils-1.4
/usr/share/doc/keyutils-1.4/LICENCE.GPL
/usr/share/doc/keyutils-1.4/README
/usr/share/keyutils
/usr/share/keyutils/request-key-debug.sh
/usr/share/man/man1/keyctl.1.gz
/usr/share/man/man5/request-key.conf.5.gz
/usr/share/man/man8/request-key.8.gz
The following lines need to be added to the end of the /etc/request-key.conf file:
create cifs.spnego * * /usr/sbin/cifs.upcall -c %k
create dns_resolver * * /usr/sbin/cifs.upcall %k
Note that if you have a newer version of cifs-utils, the -c above is not necessary (and is actually a deprecated option). After adding the lines to the request-key.conf file, you should now be able to mount the share:
# mount -t cifs //mydfsdomain.lan/namespaceroot/sharedfolder /mnt -o username=windowsuser
If all goes well, this asks for a password and mounts. Note that mydfsdomain.lan should be your Active Directory name namespaceroot should be the root that you create using DFS Management in MMC. Note that all read/write/modify operations will be performed as the «windowsuser» user in the example above.
Linux mount windows dfs
I’m on Ubuntu LTS (20.04) and trying to find a way to access my corporate network share. I’m connecting via SSTP VPN, I’ve checked the properties of the network share on my work PC, it’s a DFS share (and uses 3 different locations?).
I’ve been battling with this for a few days now and I’ve manage to come close. I can mount the main location and it shows the folders within the share, but when i try to open one of them to view the contents below, i get an error «This location could not be displayed — Sorry could not display all the contents of ». Error opening directory »: Interrupted system call».
The command I use to mount the location is:
sudo mount -t cifs //P ATH/to/share/location /home//WorkShare —verbose -o credentials=~/cred.file
This appears to work, no errors given, asks for local user password, mounts, i see the mount, I can click it, I can see the locations with the mount, but when i select one of the folders within. no bueno.
What am I missing? If you need any more info please let me know!
UPDATE: I’ve had a look at the output in journalctl and i can see that it’s trying to mount the other servers in the DFS (as mentioned earlier it looks like there’s 3 in total). But it’s failing with key.dns_resolver[31503]: symbiote: No address associated with name — I’m not totally sure what this means and googling so far has proved less than helpful. However.. I tried to ping one of the servers using the domain name and it failed, i tried to ping the same server but using the IP and it worked perfectly find. So now I’m wondering if perhaps there’s a problem with the DNS lookup. I’ll keep digging and add info if I come across anything useful.
UPDATE 2 (SOLUTION): The problem was that although I was connecting to the VPN and the initial connection to the network share was being resolved (somehow) the additional server were failing to connect when they were being switched to as i tried to browse the network share. I added the two search domains my company uses to the VPN (using nm-connection-editor, edit VPN, list the
domains). Once this change was made I was able to mount the drive again and switching folders works like a charm!
For anyone looking to mount a Windows DFS share (working on Ubuntu 20.04) you should be able to by following the following instructions:
- Install cifs-utils and keyutils
- Create a credentials file to use for your mount command (or use inline username/password)
- Make sure that you can resolve short hostnames (eg. server1 rather than server1.example.com ). If not add your additional search domains to your VPN or connection using nm-connection-editor (Select your connection, click the gear, add list of search domains)
- Mount the DFS;
- inline login: sudo mount.cifs //server.company.name .com/Folder /path/to/mount/location -o username=username,password=Pa$$w0rd
- credentials file: sudo mount.cifs //server.company.name .com/Folder /path/to/mount/location -o credentials=/etc/cred.file
I hope this might help someone in the future! (also if this doesn’t work please comment with additional info, or if you see something wrong with the instructions please let me know, this is from memory)
Mounting a Windows DFS share on Debian box
I’m trying to mount a Windows Server 2012 backed DFS, which uses a fully qualified domain name, on my Debian linux machine with limited success. So, what I first tried was:
mount -t cifs //mydfsdomain/namespaceroot/sharedfolder /mnt/sharedfolder -o username=un,password='pw',workgroup=WORKGROUPAfter some googling, I was told I needed to pass the argument sec=ntlm or other sec variants, but these tend to result in the following error message:
I’ve tried lots of Googling and followed what was suggested here and here, but I still see the same error messages. A little information about the machines. The client is running Debian 5.0.10 and the server is a Windows Server 2012 R2 Standard 9600. Thanks in advance!
1 Answer 1
I’ve been wrestling with mounting a Windows DFS as well. I got mine (Debian 3.16.0) to mount OK. Here are a few ‘gatchas’ that I came across. Maybe some of them will help you:
The Mike’s Technology blog that you referenced mentioned that the -c option for cifs.spnego in /etc/request-key.conf is deprecated. Be sure you skip that option. I don’t use the -t option in the dns_resolver line either. See this page for descriptions of the options.
I haven’t had to use any of the sec arguments so I can’t speak to those.
Another workaround I had to use was to mount directly to the //server name/share name at the root of the DFS tree rather than resolving the FQDN. You can find the server a Windows computer is connecting to using the techniques in Clint Boessen’s Blog. I wasn’t able to find a useful reference for finding server names in Linux.
Once I got a portion of the DFS mounted, I found that it still had trouble resolving the links to other servers. I added a mount option actimeo=0 and this seemed to resolve some sort of attribute caching problem that resulted in an error object is remote . Probably not your problem but one you’re likely to run into later.