16.2 Common Errors

• Windows clients need to be rebooted if a previously mounted non-DFS share is made a DFS root or vice versa. A better way is to introduce a new share and make it the DFS root.

• Currently, there's a restriction that msdfs symlink names should all be lowercase.

• For security purposes, the directory acting as the root of the DFS tree should have ownership and permissions set so only designated users can modify the symbolic links in the directory.

16.2.1 MSDFS UNIX Path Is Case-Critical

A network administrator sent advice to the Samba mailing list after a long sessions trying to determine why DFS was not working. His advice is worth noting.

" I spent some time trying to figure out why my particular dfs root wasn't working. I noted in the documenation that the symlink should be in all lowercase. It should be amended that the entire path to the symlink should all be in lowercase as well. "

For example, I had a share defined as such:

 [pub] path = /export/home/Shares/public_share msdfs root = yes 

and I could not make my Windows 9x/Me (with the dfs client installed) follow this symlink:

 damage1 -> msdfs:damage\test-share 

Running a debug level of 10 reveals:

 [2003/08/20 11:40:33, 5] msdfs/msdfs.c:is_msdfs_link(176) is_msdfs_link: /export/home/shares/public_share/* does not exist. 

Curious. So I changed the directory name from .../Shares/... to .../shares/... (along with my service definition) and it worked!