CIFS Client and Samba DFS Root

[Viktor Holmberg]

Hi there Again,

Here is a problem I have been working on. I would like to Centralise all my windows to unix transfer directories into One DFS root share. If I create a DFS_Root on a Windows servers and have re-directs to other windows servers in that share, the CIFS Client on unix works 100%. Unfortunately I don't want to build a dependence on a Windows DFS share. If the window server is down, then I will not be able to get to any other share, even if they are on other server.

Hence I was thinking about using Samba and the DFS Root option. So I set up Samba with a redirection and I can successfully connect from windows and get redirected but the CIFS client does seem to be able to follow the redirection. See Below:

# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 532480 284040 246576 54% /
/dev/vg00/lvol1 311296 185224 125120 60% /stand
/dev/vg00/lvol8 8904704 2449944 6404384 28% /var
/dev/vg00/lvol7 7675904 3048112 4592416 40% /usr
/dev/vg00/lvol4 1048576 90776 950928 9% /tmp
HOFILE:/IT 292959224 238511216 54448008 81% /hofile/IT
DEV-ORA:/DFS_ROOT 532480 285904 246576 54% /dev-ora/dfsroot
# cd /dev-ora/dfsroot/
# ls -al
total 2
drwxr-xr-x 2 root sys 0 May 31 13:03 .
drwxr-xr-x 3 root sys 96 May 31 10:24 ..
lrwxr-xr-x 1 root sys 15 May 31 12:53 it_share -> msdfs:hofile\it
-rw-r--r-- 1 root sys 0 May 31 13:03 vvv
# cd it_share
ksh: it_share: not found
#

The question is, can the CIFS client follow the msdfs redirection link in Samba? Or I am I doing something wrong?

Regards

Viktor

[Steven E. Protter]

Shalom,

There are known problems between DFS and anything but the latest samba/cifs/9000 release from http://software.hp.com

At the very least update the client on HP-UX, which requires a reboot.

SEP

[Eric Raeburn]

Viktor,

The HP CIFS Client DFS feature was tested in the lab against HP CIFS Server A.02.02.01, so it should work, although it is still possible you could have found a bug.

Without seeing a network trace it is difficult to know where the problem lies. I suggest first trying to troubleshoot by trying to get a Windows client to follow the DFS link on the Samba server. If the Windows client works, there may indeed be a problem with the CIFS Client; if the Windows client fails, the problem is likely with your Samba configuration.

-Eric

[Viktor Holmberg]

Thanks Eric

I have reinstalled a new Hp-UX 11i V3 server:

rx6600: / # cifslist -v
HP CIFS Client A.02.02.01
rx6600: / #

For windows I can follow the redirection but this unix host, which has the dfsroot share mounted it does not work.

---------- Original Samba directory ----------
rx6600: / # cd /dfsroot/
rx6600: /dfsroot # ls -al
total 16
drwxrwxr-x 2 root sys 96 Jun 19 10:12 .
drwxr-xr-x 25 root root 8192 Jun 19 14:08 ..
lrwxrwxr-x 1 root sys 26 Jun 19 10:11 downloads -> msdfs:itopsadmin\downloads
lrwxrwxr-x 1 root sys 15 Jun 19 10:12 it -> msdfs:hofile\it


---------- Mounted Samba Share ---------
rx6600: /dfsroot # cd /rx6600/dfsroot/
rx6600: /rx6600/dfsroot # ls -al
total 6
drwxrwxr-x 2 root sys 0 Jun 19 10:12 .
drwxrwxr-x 3 root sys 96 Jun 19 14:08 ..
drwxrwxrwx 2 root sys 131072 Jun 20 10:09 downloads
drwxrwxrwx 2 root sys 131072 Jun 20 10:09 it
rx6600: /rx6600/dfsroot # cd it
ksh: it: bad directory
rx6600: /rx6600/dfsroot # ls it
it unreadable
rx6600: /rx6600/dfsroot #

rx6600: /rx6600/dfsroot # cifslist
Mounted Object Mountpoint State
-------------------------------------------------------------------------------
\\HOFILE\IT /hofile/it M
\\RX6600\DFS_ROOT /rx6600/dfsroot M
===============================================================================
Server Local User Remote User Domain State
-------------------------------------------------------------------------------
hofile root viktor.holmberg L
itopsadmin root viktor.holmberg L
rx6600 root viktor.holmberg L
rx6600: /rx6600/dfsroot #


The later version of cifsclient can now "see" the link however it will not follow it to the remote server.

Any ideas?

Regards

Viktor

[Eric Raeburn]

Viktor,

The CIFS Client DFS feature has been tested with DFS links on Samba servers, both the HP flavor (HP CIFS Server) and Samba on Linux.

There are subtleties in the server configuration and there may be some domain-membership dependencies for the servers in the DFS tree.

Have a look at these:

docs.hp.com/en/6485/ConfigtroubDFS.pdf
www.samba.org/samba/docs/man/Samba-HOWTO-Collection/msdfs.html

If those don't solve it, your best bet is to open a call with HP support.

Please post your results. Thanks,
-Eric

[Eric Raeburn · Accepted solution]

Viktor,

I've been looking into this problem during the last couple of days and found there is indeed a problem between the cifs client and samba with respect to dfs, but I am happy to report there are two solutions.

First solution:
Set "unixExtensions = no;" in the cifs client configuration file. For the setting to take effect, the client must completely disconnect from the Samba server whose share contains the dfs links. This means executing cifslogout and cifsumount, such that the server is not seen anywhere in the output of cifslist. Or alternatively (and easier), just do "cifsclient restart".

Second solution:
This is more annoying, but has the benefit of not disabling Unix Extensions. Assuming you have /mountpoint/dfs_link, and dsf_link points to some other share, then if you do

ls /mountpoint/dfs_link

before doing

ls /mountpoint

you will circumvent the problem. If mountpoint contains multiple dfs links, you must do 'ls' on the absolute path, as in the example above, on each dfs link, before you ever do 'ls' on the mountpoint. I know this is ugly, but it does avoid the problem. You could script the whole thing to do the appropriate 'ls' commands immediately after mounting the share and before any users access the mountpoint.

Here are the gory details, if you or anyone else is interested:

Samba implements dfs links as symbolic links, which you already know, having set this up. For Windows clients, for which the implementation was intended, this is not a problem, since symbolic links are unknown to Windows filesystems. The implementation in effect fakes out the Windows client.

But for the HP CIFS Client, with Unix Extensions enabled, a symbolic link is a symbolic link and a dfs link is a dfs link. If the cifs client does 'ls' on just the mountpoint first, the (unix-extensions enabled) Samba server tells the client the dfs link is a symbolic link, which it is on its local filesystem, even though functionally it isn't expected to act like a symbolic link. Then when the cifs client attempts to follow the dfs link under the mountpoint, it accesses it as a symbolic link (because that's what Samba told it it was). But this causes the Samba server to return an error, because functionally Samba regards it as a dfs link. And that is the problem.

It may be possible to enhance the cifs client to work around this implementation. I would not say the chances are good we could devote resources to this, however. Another possibility would be to report this to the Samba team (samba.org). The Unix Extensions are important to them, so they might consider reworking the dfs implementation.

Good luck. Post your results so I know your setup is working.
-Eric

[Eric Raeburn]

Viktor,

As you probably realized from my explanation, using a Windows server instead of Samba as the host of the dfs_root share would also avoid the problem. I guess one could consider this yet a third workaround.

-Eric

[Viktor Holmberg]

Thanks Eric,

I tried both methods and they work as expected. Since I will not be using any Unix attributes on the shares, the unixExtension=no is the best solution for me. Also, it allows you to browes for available shares, which you can not do with the other option. You have to know the full path to the share/file you are looking for.

The HP link below, HP CIFS Client Features, mentions the limitation.
http://www.docs.hp.com/en/B8724-90079/ch01s03.html

It is allows easy to find the documenation once you know what you are looking for :-)

Thanks Again for you help.

Viktor

[Viktor Holmberg]

See my last post and Eric's last two posts.

Thanks Again

Viktor