8.7 Microsoft Distributed Filesystems

In a large network where many shared folders are spread out over a large number of servers, it can be difficult for users to locate the resources they are trying to find. Browsing through Network Neighborhood or My Network Places can become an ordeal rather than a time-saving convenience. To mitigate this problem, Microsoft added an extension to file sharing called Distributed filesystem (Dfs). Using Dfs, it is possible to organize file shares on the network so that they appear to users as organized in a single directory tree on a single server, regardless of which servers on the network actually contain the resources. Instead of having to browse the entire network, users can go to the Dfs share and locate their data much more easily.

Dfs can also help administrators because it provides a level of indirection between the name of a shared folder and its actual location. The Dfs share contains references to resources on the network, and when a resource is accessed, the Dfs server hands the client off to the actual server of the resource. When moving resources to another computer, the reference to the resource in the Dfs share can be redirected to the new location in one step, with the change being entirely seamless for users.

To a limited extent, Dfs also can help improve performance for read-only shares because it provides load balancing. It is possible to set up a Dfs reference to point to identical shares on two or more servers. The Dfs server then divides requests between the servers, dividing the client load among them. However, this works well only for static, read-only data because no provision is included in Dfs for synchronization among the servers when changes are made on any of them.

8.7.1 Windows Dfs Clients

Modern versions of Windows come with client-side support for Dfs, and no extra configuration is required. Support is more limited for older versions, however. Windows for Workgroups cannot function as a Dfs client at all. Windows NT 4.0 must be upgraded to at least Service Pack 3 to act as a Dfs client, and the Dfs Client must be installed. Later service packs (such as Service Pack 6) include the Dfs Client. Windows 95 must also have the Dfs Client software installed to act as a Dfs client. Without the Dfs Client software, double-clicking a remote folder in a Dfs share will show an empty folder, and no error message will appear.

To use the Dfs Client for Windows 95 or Windows NT, you must first download and install it. See the web page http://microsoft.com/ntserver/nts/downloads/winfeatures/NTSDistrFile/default.asp for a link to download the installation program and instructions on how to install the Dfs Client.

8.7.2 Configuring Samba for Dfs

To act as a Dfs server, Samba 2.2 must be compiled with the --with- msdfs configure option. (See Chapter 2 for instructions on configuring and compiling Samba.) Samba 3.0 includes Dfs support by default and does not need to be compiled with the --with-msdfs configure option.

Once a Dfs-enabled Samba server is running, there are just two steps to serving a Dfs share. First we will set up a Dfs root directory on the server, and then we will modify the smb.conf configuration file to enable the share.

8.7.2.1 Setting up the Dfs root

First we need to create a directory to act as the Dfs root:

 #  mkdir /usr/local/samba/dfs  

This can be any directory, but it is important that it be owned by root and given the proper permissions:

 #  chown root:root /usr/local/samba/dfs  #  chmod 755 /usr/local/samba/dfs  

The Dfs directory tree can have subdirectories and files, just like any other shared directory. These will function just as they would in any other share, allowing clients to access the directories and files on the Samba server. The whole idea of Dfs, though, is to gather together shares on other servers by making references to them in the Dfs tree. The way this is implemented with Samba involves a clever use of symbolic links, which can be in the Dfs root directory or any subdirectory in the Dfs tree.

You are probably familiar with using symbolic links to create references to files that exist on the same system, and perhaps crossing a local filesystem boundary (which ordinary Unix links cannot do). But maybe you didn't know that symbolic links have a more general functionality. Although we can't display its contents directly, as we could with a text or binary file, a symbolic link "contains" an ASCII text string naming what the link points to. For example, take a look at the listing for these symbolic links:

 $  ls -l wrdlnk alnk  lrwxrwxrwx    1 jay      jay            15 Mar 14 06:50 wrdlnk -> /usr/dict/words lrwxrwxrwx    1 jay      jay             9 Mar 14 06:53 alnk -> dreamtime 

As you can infer from the size of the wrdlnk link (15 bytes), the string /usr/dict/words is encoded into it. The size of alnk (9 bytes) is smaller, corresponding to the shorter name of dreamtime .

Now let's create a link in our Dfs root for an SMB share:

 #  cd /usr/local/samba/dfs  #  ln -s 'msdfs:maya\e' maya-e  #  ls -l maya-e  lrwxrwxrwx    1 root     root           12 Mar 13 17:34 maya-e -> msdfs:maya\e 

This link might appear as a "broken" link in a directory listing because it points to something that isn't a file on the local system. For example, the file command will report:

 $  file maya-e  maya-e: broken symbolic link to msdfs:maya\e 

However, maya-e is a valid reference to the \\maya\e share when used with Samba's Dfs support. When Samba encounters this file, it sees the leading msdfs : and interprets the rest as the name of a remote share. The client is then redirected to the remote share.

When creating links in the Dfs root directory, simply follow the same format, which in general is msdfs : server \ share . Note that this is similar to a UNC appended onto the msdfs : string, except that in this case, the two backslashes preceding the server's name are omitted.

The names for the symbolic links in Dfs shares must be in all lowercase.

In addition to regular network shares, you can use symbolic links of this type to reference Dfs shares on other Dfs servers. However, referencing printer shares does not work. Dfs is for sharing files only.

8.7.2.2 Load balancing

To set up a load-balancing Dfs share, create the symbolic link like this:

 #  ln -s 'msdfs:toltec\data,msdfs:mixtec\data' lb-data  

That is, simply use a list of shares separated by commas as the reference. Remember, it is up to you to make sure the shared folders remain identical. Set up permissions on the servers to make the shares read-only to users.

The last thing we need to do is to modify the smb.conf file to define the Dfs root share and add Dfs support. The Dfs root is added as a share definition:

 [dfs]     path = /usr/local/samba/dfs     msdfs root = yes 

You can use any name you like for the share. The path is set to the Dfs root directory we just set up, and the parameter msdfs root = yes tells Samba that this share is a Dfs root.

To enable support for Dfs in the server, we need to add one line to the [global] section:

 [global]     host msdfs = yes 

Restart the Samba daemons ”or just wait a minute for them to reread the configuration file ”and you will see the new share from Windows clients. If you have trouble accessing any of the remote shares in the Dfs share, recheck your symbolic links to make sure they were created correctly.

If you previously had a share by the same name as your Dfs share, you might need to reboot Windows clients before they can access the share as a Dfs share.