Infrastructure Software

Hi,

I have an installation of Solaris 11 Express snv_151a with its CIFS server set up on a Windows Server 2008 Active Directory domain (in a Server 2003 forest). Sharing filesystems with Windows clients is working fine. Now I am trying to set up a stand-alone DFS namespace, but it's been bumpy so far. It doesn't help that the DFS functionality is virtually undocumented save for some old proposals.

Using the GUI tools in Windows has been fruitless. I've had a little more luck from the Windows command line but still not quite there.

If I manually set an SMB share to dfsroot=true, then I can see it from the Windows Server 2008 system using the dfsutil Root command, and likewise turning off dfsroot has the effect of making that command not see anything, so the dfsroot property and the management API is working to some degree.

I can even use dfsutil Link Add to create links which it can list back, and which also show up in the ZFS filesystem as reparse points (which ls -la lists such as "hah -> @{REPARSE@{SMB-DFS:1:1:0:1800:dce1a8e3-8061-ca37-a719-c2ad11b32736:1:0::EBONNIE:test2:2:0:0}}").

These appear to Windows clients as folders, but attempting to open them invariably results in an error stating "The network location cannot be reached." From Microsoft documentation, this behaviour is consistent with trying to open the link folder locally on the root server, where it is an NTFS reparse point and can't be followed except by the DFS network redirector.

Furthermore, any folder in the real DFS as implemented in Windows Server will have a DFS tab in its Properties dialog in Windows Explorer. The link folders Solaris is making do not have the DFS tab.

From this it seems that somehow Solaris is not telling the Windows clients that the DFS root isn't just another SMB share, and consequently they're using the SMB redirector instead of the DFS redirector. I know that which redirector to use for a UNC path is determined in Windows clients by mup.sys, but I don't know specifically how it knows which to use.

It's also worth mentioning that Solaris seems to have very little concept of which share is responsible for the DFS root; I can list different SMB shares published by the Solaris box as the argument to dfsutil Root and the output is identical.

I also cannot use dfsutil Root AddStd, which results in the following error:

Could not execute the command successfully
SYSTEM ERROR - The procedure number is out of range.

As such I have only been able to test adding links by first setting dfsroot=true manually via ZFS. Perhaps this fails to set up something that dfsutil Root AddStd would have?

Just for reference, here's what the GUI tools do:

In the DFS Management console from Windows Server 2008, if I use the 'New Namespace Wizard', naming the Solaris box, I am told "The Distributed File System service is not installed on the server." (Puzzlingly, the result is not the same if I use the FQDN instead of the NetBIOS name. In this case I get "ebonnie.bla.blabla.com: The service control manager cannot be opened. Access is denied".)

In the same console, I've also tried the 'Add Namespaces to Display' dialog. If there is no dfsroot=true SMB share, then I get, not surprisingly, "The namespaces on EBONNIE cannot be enumerated. Element not found". (If I use the FQDN instead of the NetBIOS name, however, I get "The namespaces on EBONNIE cannot be enumerated. Access is denied" instead.)

If I set dfsroot=true on an SMB share, then the Add Namespaces to Display dialog will instead say, "An item with the same key has already been added" although nothing from the Solaris box shows in the tree. (Again, using the FQDN gets an "Access is denied" instead.)

While it shouldn't really matter, I'll disclose:

- All those tests from Windows Server 2008 were done on the (only) AD domain controller on the network, which is also the (only) DNS and DHCP server. (All of the servers have static IPs and are in DNS.)

- The Solaris box is also hosting SMB shares (in the same, non-root zpool) that are referenced from a domain-based DFS namespace for which the AD domain controller is the (only) root server, but these are not involved in the tests discussed.

- The Solaris box is running under VMware ESXi 3.5 (mostly due to problems getting Solaris to directly recognize SATA drives and also the 1TB HDD limit on the 32-bit version).

There's very little mention anywhere of MS-DFS on Solaris, even though it's obviously implemented at least to some degree. Has anyone managed to get it working? Any ideas on what I may be missing?

Thank you in advance for any help.

Regards,
Kevin