none
Windows 7 Clients unable to traverse dfs folder hierarchy

    Question

  • We are currently experiencing an issue that for some reason has stumped me and I can't determine how to continue troubleshooting it.

    Our Windows 7 clients (standard users) are no longer able to traverse our dfs folder structure, but Windows XP (same user) do not experience said issue. They are still able to access what they have permission to by \\unc, shortcut, or mapped drive. I am not sure how long this issue has persisted, as it was just reported yesterday. No permissions have been changed.

    I created a folder structure with the same permissions and they don't experience the issue. These permissions have been in place for 18 months with no issues until now.

    Permissions taken from here (KB27443):

    • CREATOR OWNER - Full Control  (Apply onto: Subfolders and Files Only)
    • System - Full Control (Apply onto: This Folder, Subfolders and Files)
    • Domain Admins - Full Control (Apply onto: This Folder, Subfolders and Files)
    • Everyone - Create Folder/Append Data (Apply onto: This Folder Only)
    • Everyone - List Folder/Read Data (Apply onto: This Folder Only)
    • Everyone - Read Attributes (Apply onto: This Folder Only)

    Nothing appears to be corrupt, I don't get any error messages beyond the standard unable to access which points to a permissions problem. I am toying with removing and reapplying the permission, but not sure if that will force a full replication of dfs (the permissions are This Folder Only).

    • Windows Server 2008 R2 w/DFS 2008
    • Windows 7 SP1 fully patched
    • Windows XP SP3 fully patched
    Wednesday, April 04, 2012 3:19 PM

Answers

  • Like this?

    And use will get access denied error when trying to access \\shan.com\dfs\users or \\shan.com\dfs\users\share?

    If the structure here is correct, then as there is no folder target assigned to "users" and "shares", those folders should be found in c:\DFSRoots by default.

    Please check the permission set there and see if users do have correct permission.


    TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

    Wednesday, April 11, 2012 2:02 AM

All replies

  • It should not be a permission related issue as same user encounter different results on different operation system.

    As you mentioned "\\UNC, shortcut and mapped drive" will work. I would like to know the exact path of the mapped drive and the shortcut.

    Also please let us know which one is not working:

    \\domain

    \\domain.com

    \\domain.com\namespace


    TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

    Friday, April 06, 2012 7:33 AM
  • Thanks for the reply. Is is the information as requested:

    We automatically map drives through GPP according to Security Groups. So a mapped drive would look as follows:

    The root of our dfs share has three folders: shares, temp, and users (only the users and shares folder has issues, since they don't have r/w access on the folder, only the permissions in original post)

    \\domain.com\dfs\users\ would map to O:\ (root of dfs share)
    \\domain.com\dfs\users\shares\department would map to the S:\ (departmental share via security group filtering)
    \\domain.com\dfs\users\temp would map to the T:\ (Temp drive, all users have r/w access but can't delete the root folder)

    Homefolders (H:\) are handled through the user account in AD mapped to the \\domain.com\dfs\users\users\%username%

    Shortcuts are typically O:\[shortcut to folder] so are via mapped drive.

    For \\unc testing purposes, I can unc via:

    \\domain.com\dfs\users\shares\folder and get there if they have permission. I can't unc to shares or users root folder but can to dfs root.

    I also tried \\unc to the hidden share on the server itself to bypass dfs, such as \\server\share$ and can access the root of the share, just not \shares or \users, but still can to direct folder they have access to.

    Of course all of this doesn't pose a problem on XP SP3, only Windows 7. After further testing, it isn't all Windows 7 machines either. Some have been deployed for quite some time, others we have just begun to deploy, and its a mixture of both that can or can't access things properly.

    Last night I did give up and decide to reapply the Everyone permission at the shares folder. This then allowed access as expected on all machines that were previously unable to access it. The users folder is still not working, as I haven't reapplied the permission yet. So while it makes no sense that its a permissions issue, this worked.

    So far I have:

    • Saved permissions via icacls to see if they would export (typically fails if corrupted)
    • Removed an affected machine from domain and readded
    • Parsed security logs on both machines
    • Forced a rebuild of Offline Files db via reg key
    • Isolated machine in OU with gpo block inheritance set

    Friday, April 06, 2012 1:31 PM
  • Like this?

    And use will get access denied error when trying to access \\shan.com\dfs\users or \\shan.com\dfs\users\share?

    If the structure here is correct, then as there is no folder target assigned to "users" and "shares", those folders should be found in c:\DFSRoots by default.

    Please check the permission set there and see if users do have correct permission.


    TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

    Wednesday, April 11, 2012 2:02 AM
  • We had the same issue I believe.  Ours had to do with "Bypass Traverse Checking" which is enabled by default on 2003 and disabled on 2008.  There is a group policy setting where you can change it, but the real issue is that you need the "Traverse Folder" Permission on the folder.  "traverse folder" allows drive mapping, "List folder" allows unc pathing.  In 2003, anonymous users were allowed traverse, so that permission didn't make a difference whether it was set or not.
    Monday, June 11, 2012 2:22 PM
  • I need to bring this thread back to life as we have been rolling out W7 and this is now a bigger issue than before when it was only a few clients.

    Here is my dfs structure:

    \\domain.org\dfs
    ->users
    -->shares
    --->30x department share folders
    -->temp
    -->users
    --->350x user folders
    ->software

    The user and share folders have the EXACT NTFS permissions. They sit at the exact same level in DFS inside of the same target. They aren't stored in a seperate partition, drive, etc. A W7 user is able to access the users folder no issue and then only their own user folder. They are unable to access the shares folder unless they use the exact \\unc path to a folder they have access to.

    As per Exch2010Admin suggestion, I added the "Traverse folder / execute file" permission and allowed that to replicate. No change.

    This isn't a dfs issue as I can \\unc and experience the exact same results. The even stranger thing is only 1/4 file servers works. One of them allows the end user to access the "shares" folder while the other three don't. No differences in ntfs permissions at all. The only difference is this server is W2k8 vs the other three being W2k8R2.


    • Edited by Craig R3 Tuesday, April 30, 2013 9:46 PM
    Tuesday, April 30, 2013 9:44 PM