Microsoft AD DFS Shares and Mac 10.8

[lutey]

Supposedly 10.8 supports DFS shares, but we can't get it to work. Anyone have any success mounting DFS shares? We have a domain ad.unlv.edu, and a DFS share of ADStudentsGroupsSample and am connecting to server smb://ad.unlv.edu/Student/Groups/Sample - it asks for a network/password if I'm not connected to domain, if I i'm connected to the domain it just fails? Thanks for any help !!

[ClassyLee]

Actually, as of 10.7 OS X supports DFS shares...

We've been using DFS at our company since 10.7 and we're rather pleased with the improvements that Apple made in 10.8. It by no means is perfect but I'm glad they finally implemented it.

Can you provide more information about your set up? What kind of information do you get when you connect to your DFS share and then use the following utility from the command line: smbutil dfs smb://ad.unlv.edu/Student/Groups/Sample

Do you get a list of servers and referrals? Are you using kerberos in your domain, if so can you verify that it's been configured correctly? Have you looked at the following Apple KB for help? --> http://support.apple.com/kb/HT4794

[gregp]

Works fine here as well. The servers are a bunch of NetApp vFilers. The Macs have no problem with going to the DFS share or connecting directly.

[adkinsan]

We are seeing odd behavior in accessing DFS shares from 10.8.3 that seems dependent on the length of the path to the share. While 10.8.3 Macs are able to access smb://server/share/share, they cannot go further than the second share. The folders appear, but they are blank. We've verified that the folders contain data, and that users have proper access rights to the folder by way of them accessing the data via Windows7 VMs on the same Mac.

Looking through to see what the limiter may be, perhaps the 2KB limit from 10.8.0 is getting in the way? I read mixed reports that it was addressed in 10.8.1.

[jwojda]

do they have a high amount of subfiles/folders? We have a long delay when displaying ours and found a several millisecond delay per file/folder it needs to enumerate that doens't exist on the Wintel machines. It may take 60-70 seconds for our folders to display. We also found that doing it through the CLI didn't exhibit these delays (I don't recall the exact command execution as we did this testing about a year ago).

[antoinekinch]

If Jwoda or anyone has found a cure for the performance of browsing the subfiles and folders please post it. I am hoping that in future implementations of Apple's SMB that DFS share performance improves. I have users that are in Tokyo & Hong Kong that have issues natively reading from the Mac but when using their Windows VM's/Blades there are no problems.

[lisacherie]

Reviving this with a "me too" for the performance issues, particularly over WLAN when compared to PCs.

Did anyone find any good workarounds, or tuning?

[dmw3]

We have DFS working, but found a quirk in that permissions did not work correctly if some share names were all lower case names. Or there was a folder in the users Home that was the same but in a different case on the DFS path e.g. "Home" works but "home" did not.

[Over9000]

We are currently experiencing this issue now as well. Has anyone found a solution to the problem?

[alexjdale]

One thing to check is to see if it matters if the user mounting the share has full read permissions through the path (and not just the share at the end). I am pretty sure that has caused failures for us.

Also, a lot of the time, Kerberos is a requirement and even though it prompts for NTLM authentication, it will always fail.

[tsc_mike]

Accessing DFS shares are very very slow for us. I have used Wireshark to do a network trace. I have analyzed the logs and from what I can see there is not a delay in the response from either my DNS or DFS server but I can see that my Mac is enumerating every single folder inside the DFS root namespace.

The logs show these events:
"DFSC:Get DFS Referral Request, FileName: DFSServerNamespaceFolder' MaxReferralLevel: 4"

This repeats over and over again for every folder within the namespace. It can take 30-45 minutes for the Mac to finish and display the shares contents.

These are shares that are on a NetApp filer. If the Mac goes directly to the NetApp's DNS name or IP bypassing DFS the connection happens really quickly.

Has anyone come across this issue before or know what might be causing this?

[jwojda]

Yes, we even had Apple Professional Services come onsite, had tickets with M$ and Apple and had them on conference calls. No resolution. It's just slow.

You can try PathFinder (free trial) see if that helps, it uses a different painting method from Finder, it seemed to be better, but not great.

[tsc_mike]

So I'm still in the process of testing this but it's looking promising. Our DFS did not have FQDN's enabled.
http://markparris.co.uk/2010/03/19/configure-dfs-namepaces-to-use-fully-qualified-domain-names-its-not-the-default/
http://support.microsoft.com/kb/244380/en-us
I've done this on a test DFS server and namespace and the Mac's will display the contents much much quicker. Our "Users" namespace that has roughly 280 target folders would take 30-45 minutes to display. It now takes about 45 seconds.

[lisacherie]

@tsc_mike Thanks for sharing.

Has anyone else had any success with tuning for better mac performance?

We have open enterprise tickets with Apple, just wondering what suggestions anyone else has received if any or if you also have open tickets?

[charles_hitch]

One item we are testing is changing the TCP ACK setting from its default to 2. This is recommended by EMC the vendor for our SAN system.

#!/bin/sh
/usr/sbin/sysctl -w net.inet.tcp.delayed_ack=2

I don't have any results from this testing, so if anyone else has tried this and has any input it is certainly welcome.

[lisacherie]

Tried changing these settings a while ago with earlier dot releases of 10.8, didn't make any noticeable difference for performance.

Are you testing with 10.8.X or 10.9.X?

Please share your results would be good to re-visit if it helps.

[theraven]

I found this explanation of this issue on the Apple discussion site.
It turns out that Mac OS X 10.9 will not follow path-based DFS referrals handed out by Samba. It turns out that this seems to be because Samba does not actually do what Windows does with such things. Firstly, Windows adds FILE_ATTRIBUTE_REPARSE_POINT to all directory entries that are DFS junction points in a FIND (FIND FIRST/FIND NEXT) response (SMB_FIND_ID_BOTH_DIRECTORY_INFO and others)). Secondly, Windows places IO_REPARSE_TAG_DFS in the EA size field for reasons known only to MS. With these two changes, Mac OS X 10.9 will happily follow path-based DFS links.

[jwojda]

@theraven so does that mean something can be modified to allow it to work better or are we waiting on a patch from Apple?

[dvasquez]

We use DFS in our environment. I use this syntax to mount our shares on our Mac clients:

smb://[domain;][user[:password]@]server/dfsroot/dfslink

When mounting from the Finder if you withhold the password in the command you should be prompted.

Not sure if this help you. We are running nothing lower than 10.9.5. So this works for us.

As far as tuning I believe the native protocol for 10.8.5 - 10.9.5 is SMB2. We have had issues in the past leveraging SMB from the Windows servers when the Mac clients are using SMB2 but now our Windows INF has been upgraded and we are using SMB2 as a native protocol globally. With that implementation and the migration of legacy shares to DFS the slowness in mounts and file enumeration has been significantly decreased.

I have tested the sysctl tuning mentioned by charles.hitch. I agree with lisacherie we did not see significant improvement.

[donparfet]

The problem I ran into with DFS shares on our campus network was that DHCP Search Domains were not defined, so the named instance was not resolving correctly. Once I manually added the appropriate DHCP search domain, logged in AD users were able to access the DFS shares successfully. Here is a further discussion on the subject:
We are experiencing a similar problem here. It all has to do with DNS.

Our DHCP server gives all clients a default search domain of indiana.edu, but Windows clients that bind to Active Directory automatically get our AD namespace (ads.iu.edu) in addition to that. This allows Windows users to connect using only the partial DNS name (//server/share/) instead of having to use the FQDN (//server.ads.iu.edu/share/). Using the partial name is so ingrained that no ever thinks about it ... except OS X users who always have to append ads.iu.edu to any Windows servers they connect to.

Then jump to Windows admins setting up DFS shares. They configure the DFS referrals using just the partial server name. This is fine for Windows clients, but nobody else can resolve the referral:

$ smbutil dfs smb://ads.iu.edu/iu-esa/shared/ssl/nuget

------------- AD Domain Entries -------------
Server Name : iu-mssg-adsdc07.ads.iu.edu
Server Name : iu-mssg-adsdc08.ads.iu.edu
Server Name : iu-mssg-adsdc06.ads.iu.edu
Server Name : iu-mssg-adsdc02.ads.iu.edu
Server Name : iu-mssg-adsdc09.ads.iu.edu
Server Name : iu-mssg-adsdc05.ads.iu.edu
Server Name : iu-mssg-adsdc01.ads.iu.edu
Server Name : iu-mssg-adsdc04.ads.iu.edu
Server Name : iu-mssg-adsdc10.ads.iu.edu
Server Name : iu-mssg-adsdc03.ads.iu.edu

------------- Entry 1 -------------
Referral requested : /iu-mssg-adsdc03.ads.iu.edu/iu-esa list item 1 : Path: /iu-mssg-adsdc03.ads.iu.edu/iu-esa list item 1 : Network Address: /IU-UITS-SAFP1/IU-ESA <-- bad list item 1 : New Referral: /IU-UITS-SAFP1/IU-ESA <-- bad list item 2 : Path: /iu-mssg-adsdc03.ads.iu.edu/iu-esa list item 2 : Network Address: /IU-UITS-SAFP2/IU-ESA <-- bad list item 2 : New Referral: /IU-UITS-SAFP2/IU-ESA <-- bad

Manually adding ads.iu.edu to the client's DNS search domains solves the problem:

$ smbutil dfs smb://ads.iu.edu/iu-esa/shared/ssl/nuget

------------- AD Domain Entries -------------
Server Name : iu-mssg-adsdc06.ads.iu.edu
Server Name : iu-mssg-adsdc09.ads.iu.edu
Server Name : iu-mssg-adsdc07.ads.iu.edu
Server Name : iu-mssg-adsdc08.ads.iu.edu
Server Name : iu-mssg-adsdc03.ads.iu.edu
Server Name : iu-mssg-adsdc02.ads.iu.edu
Server Name : iu-mssg-adsdc05.ads.iu.edu
Server Name : iu-mssg-adsdc04.ads.iu.edu
Server Name : iu-mssg-adsdc10.ads.iu.edu
Server Name : iu-mssg-adsdc01.ads.iu.edu

------------- Entry 1 -------------
Referral requested : /IU-UITS-SAFP2/iu-esa/shared/ssl/nuget list item 1 : Path: /IU-UITS-SAFP2/iu-esa/shared list item 1 : Network Address: /IU-UITS-SAFP1/shared list item 1 : New Referral: /IU-UITS-SAFP1/shared/ssl/nuget list item 2 : Path: /IU-UITS-SAFP2/iu-esa/shared list item 2 : Network Address: /IU-UITS-SAFP2.ads.iu.edu/shared list item 2 : New Referral: /IU-UITS-SAFP2.ads.iu.edu/shared/ssl/nuget <-- good

------------- Entry 2 -------------
Referral requested : /iu-mssg-adsdc01.ads.iu.edu/iu-esa list item 1 : Path: /iu-mssg-adsdc01.ads.iu.edu/iu-esa list item 1 : Network Address: /IU-UITS-SAFP2/IU-ESA list item 1 : New Referral: /IU-UITS-SAFP2/IU-ESA list item 2 : Path: /iu-mssg-adsdc01.ads.iu.edu/iu-esa list item 2 : Network Address: /IU-UITS-SAFP1/IU-ESA list item 2 : New Referral: /IU-UITS-SAFP1/IU-ESA

[ronb]

After initial success utilizing DFS on our Macs with Yosemite (first time it seemed to be working effectively in a decade of trying with multiple Mac OS's) we started deploying it as the default mount point method. Only after time and multiple people testing with it did we start seeing finicky issues with volumes not being able to "mount" (previous volumes we used to mount via smb now looks like folders under our pdfs mount point until we click on them, then the icon changes to a volume, and we see the contents) sometime during the day. Initially it always seems to mount volumes early in the day. We were starting to suspect the issue creeps in after the system goes to sleep during lunch, but that has not been proven definitively yet.
Also, Adobe InDesign does not appear to be updating changes happening on these volumes. As an example, if a designer creates and saves a Photoshop file in a specific path (with InDesign already running), and then they go into InDesign to link that Photoshop file, it does not see the file in that folder. It can be seen by the Finder, just not InDesign, until they restart InDesign.
Anyone else seeing DFS issues with Macs in a Microsoft environment?

[calumhunter]

i'm pretty sure adobe does not support support accessing files over a network full stop so that might be your issue there.

DFS on yoyo works fine for us, but you have to make sure all your DNS is up to scratch and that your DFS entries/referrals are all correct.

It is still a tad slow viewing a folder with many items in it ie 1000+ compared to connecting to a smb server directly without using DFS

[JPDyson]

i'm pretty sure adobe does not support support accessing files over a network full stop

True. I've been answering questions about why working in Adobe apps with network files sucks for as long as I've been supporting Macs in enterprise. Adobe always gives the same answer: don't do it.

[ronb]

Yes they have been saying that forever. Easy for them to say. We have nearly 50 publications here, could you imagine the "sneakernetting" around here? I gather that last term is dating myself as well.

[donparfet]

we have had good results storing files on network shares, but we always encourage the designers to work on files on the local machine. attempting to work on files stored on the network has proven to be problematic to say the least...

[ronb]

donparfet - So do the designers keep their linked graphic and photo's on the server at all times, and link their local InDesign file from the server?

[donparfet]

I have had some success in teaching them to keep all linked graphics and the main project within a folder, and keeping the links relative to that folder. they either copy the whole folder up to the network or embed the graphics/photos. I just give them advice really, and help them understand how to have success. If they don't follow the recommended process and their project gets hosed, they have figured out how to pay attention...