After upgrading a number of systems to the Fall Creators edition of Windows 10, version 1709, we began receiving reports of certain users being unable to access a specific set of shared folders. These were folders hosted on a 2012R2 file server, and the error received indicated the share was missing, rather than there being a permissions issue.
Searching for this type of error on the Fall Creators edition turns up two common results:
- SMBv1 has been disabled and/or removed from Win 10 1709
- Guest access in SMB2 disabled by default in Win 10 1709
We were pretty certain SMBv1 was not in use but ran Wireshark to sniff the SMB traffic and verify SMB2 was being used.
Likewise, we knew guest account access was already disabled, and the Microsoft KB article references log entries that would be present if this were causing a problem. There were no relevant log entries, so we crossed this off the list of possible causes.
Interestingly, not all shares were an issue; even other ones on the same server worked fine. That said, this share had been used for years without problems, with multiple versions of Windows, including three previous Win 10 builds.
I started reviewing the permissions on the share, just to see what might be different from other shares that were working, and quickly found a discrepancy.
The share in question was the parent folder for many sub-folders. The sub-folders have different permissions for different groups. We provide a shortcut directly to the parent folder and have access-based enumeration enabled so that users only see the folders they have access to. Nothing all that unusual here.
The parent folder had “Authenticated Users” being granted “Traverse Folder / Execute File” on the folder itself. (“This Folder Only”)
Certain user groups however had “Read” permissions on the parent folder. Some quick testing showed that the users with “Read” permissions could access the share, while those with “Traverse Folder” could not.
The entire purpose of “Traverse Folder” is to “[a]llow..moving through a restricted folder to reach files and folders beneath the restricted folder in the folder hierarchy.” Having this permission should be perfectly sufficient for what we were doing, and it has been for years, up until the Fall Creators version of Win 10.
Even stranger though is that “bypass traverse checking,” which is granted to everyone by default (and enabled in our domain) is supposed to entirely negate the need for the “Traverse Folder” right in the first place.
Something obviously changed in Fall Creators that has broken traverse checking; my guess is with all the file system work that Microsoft acknowledges they put into Fall Creators, they either inadvertently broke this or deliberately changed the behavior without communicating it to us. Although if this were a deliberate change it completely eliminates the value of traverse bypass in the first place.
The fix here was easy; I gave “Read” permissions to “Authenticated Users” for the parent folder only. This had no effect on any of the sub folders or users access to them, but it resolved the path not found error.
Oh well…back to beta testing the latest GA build of Win 10…
Thank you for posting about this. I’ve run into a similar issue where shares were not being visible (ABE enabled). Did you ever figure out what exactly was going wrong here? In our case, newly created resources would work as intended pre-Creators Update but at some point later would stop working (disappear). Removing traversal privilege from the container after that point corrected the issue and I’ll be waiting a few days to see if it flip-flops back.
For testing purposes we used the NTFSSecurity and the following PS function to set the permissions quickly. The skeleton folder simply consisted of a hierarchy of two levels (children & grandchildren containers and objects). File resource security groups follow AGUDLP group strategy.
I wish I had more info than I already posted, but unfortunately I don’t and have been too busy chasing other random Win 10 issues to investigate this further. I think basically MS broke traverse checking in 1709. I will say that once we made the change I posted about, we have not had any further problems.
No worries, thanks for the post; quite literally it was the only cogent post on this issue, and it seems sporadic. I was working on a folder yesterday where quite clearly something was going on, and to make the folder visible for the user I had to remove the traversal privilege, but when re-creating the ACLs from scratch with a new resource, traversal was necessary.
I didn’t run into your problem exactly because our users already had parent directory privileges. I did notice the only users having issues had both Traversal & Generic Read checked, and removing traversal fixed it temporarily. Ultimately I ended up recreating the resource and the issue didn’t manifest after that (so far).
Fall Creators update brought us some headaches. This post solved one of those problems that wore being very hard to find out the solution. Some of our shared folders are configured with based enumeration enabled and those woren’t acessible.
Thank you for you post.
Greetings from Portugal
Great, glad to hear it helped!
i had similar issues. found it rather odd that once 1709 was installed network file access from my server changed. my mysterious issue is that my two Oppo Players can no longer access the network and these are the only devices that cannot see the network. i have other 1709 issues but not relevant to this topic.
James did you ever get anywhere with this issue? I am opening a case with MS today regarding EXACTLY the same thing happening in 170 all the way to 1903
John, I made the change detailed in the original post, giving read access to users to the parent folder only. This resolved it and we haven’t seen it reoccur. Unless there are files in the parent folder, rather than just having sub-folders, I think this is a viable fix. Of course if you have hundreds of shares, that’s another story.
Unfortunately we do have tons of shares. I will comment back if Microsoft tells us anything of note.
Thanks for the great post!
Please do, I would be very curious to hear their response. Hopefully you have better access to support than we do; dealing with an O365 issue right now and can’t even get them to call us during our business hours.
Hi James, exactly same problem i have, same issue on Windows 1803, in which Traverse permission is not respected. Windows 7 machines are working fine. So from the file server, SMB1 is enabled but the clients are defintely using smb2 as its disabled from the registry. Even if i try to enable SMB1 on Windows 10, it still doesn’t work (or it will work but sporadic). I am quite hesistant to enable Read permission as we are dealing with Secured Network folders where we have the platform ISO certified. Once you enabled Read in conjuction with Traverse Permissions, It turns it into Read and Execute. We don’t want people to be able to run Executables from the root folder.
I wonder if John has an update with his Microsoft troubleshooting?
I can’t speak to ISO certification, but I only added read permissions to “This Folder Only.” Unless you have content in the root of the folder, this really should not pose a problem. And if users do not have write access, I assume there wouldn’t be any executables there anyway. Good luck finding a viable solution for you.
I see i thik i get what you mean now when you say Read, what i was actually doing is leaving Traverse and adding Read hence they turn into Read and Execute collectively. I removed Traverse and just left Read specifically and it works. Thanks for a great post by the way!