Section 6.4. Microsoft Distributed File Systems

6.4. Microsoft Distributed File Systems

Microsoft's Distributed File System (MS-DFS), not to be confused with the Distributed Computing Environment's DFS, is the Windows equivalent of the Unix automounter. All modern Microsoft clients (Windows 98, NT 4.0, and later) natively support MS-DFS. An add-on component for Windows 95 is available from Microsoft. Figure 6-7 illustrates how MS-DFS is implemented. MS-DFS links appear as folders when viewed by the client. When the user attempts to access the directory, he receives a referral to a UNC path ( \\CARROT\data ), which is automatically followed on his behalf by the Windows client. The user is never aware that the contents of the directory reside on another server. Because MS-DFS assumes that the credentials used to connect to the first server are also valid for connecting to the target of the referral, it is useful only within the context of an authentication domain.

Figure 6-7. Redirection by MS-DFS

Configuring Samba to support MS-DFS root shares involves one global parameter, host msdfs , and one per share parameter, msdfs root . The following configuration defines a share named [common] that acts as a MS-DFS root share. It combines group shares managed by various departments within the network and provides an alternative to the [groups] share covered earlier in this chapter. Because we use the share to store only MS-DFS links, there is no need to provide write access to the share.

[global]
    host msdfs = yes

[common]
    path = /data/dfs
    read only = yes
    msdfs root = yes

The MS-DFS referrals are stored on the server's filesystem as symbolic links. The link name is the name of the directory displayed by clients. The target of the link represents the destination UNC path for the MS-DFS referral. The link target name follows this format:

msdfs:


server


\


share


[,


server


\


share


,...]

The msdfs keyword is used by Samba to identify the link as a MS-DFS referral. The server \ share component is the path to the server and share returned to the client. Multiple paths can be defined; all will be returned the client, which then selects one based on internal heuristics.

The following ln command creates a referral from staff to \\sleet\staff :

$

ln -s 'msdfs:sleet\staff' staff

$

ls -l staff

lrwxrwxrwx  1 root root 17 2006-05-25 11:36 staff -> msdfs:sleet\staff

After reconfiguring a server or share to support MS-DFS, you will likely have to reboot the Windows client in order for it to recognize the new functionality. Once this is done, you will be able to test the MS-DFS share by browsing to the staff directory and viewing its contents. If you experience any problems at this point, verify the following:

• smb.conf contains no syntax errors and Samba as been restarted or has reread the file since the changes were made.

• The Windows client has been fully rebooted since last connecting to the Samba server.

• The target (e.g., \\sleet\staff ) of the MS-DFS referral is accessible by the client and the user credentials are also valid on that server.

If you verify these items and are still having difficulties, turn to the Samba logfiles and the steps outlined in Chapter 12 for troubleshooting help.

In addition to supporting MS-DFS referrals for directories, it is possible to define a share that solely refers to another share by specifying a path in the msdfs proxy parameter, which can be helpful when migrating services from one server to another. For example, suppose that we have moved \\RAIN\templates to \\SNOW\templates but some clients are still trying to access it in the original location. The following share redirects users to the correct share without any client modifications:

[global]
    netbios name = RAIN

[templates]
    msdfs proxy = \snow\templates

Table 6-11 lists the various MS-DFS related options that can be defined in smb.conf .

Table 6-11. MS-DFS options