User cannot get past traversed folder on first try

Question

I have, very intentionally, given users traverse rights to a shared folder on a server but write access to a subfolder. Here is the structure:

Local path on server: D:\Apps\MyAppFolder
Inside MyAppFolder is a file MyAccessApp.accde file (compiled Access front end application) and .accdb file (Access backend/table file)
Users have traverse-only to D:\Apps but read/write within D:\Apps\MyAppFolder
D:\Apps is shared as \MyServer\Apps$ and mapped via login script as S: drive.
So the path to the Access application is S:\MyApp\MyAccessApp.accde
The $ in the share name hides it so nobody can browse there without explicitly knowing about it.

The traverse-only to the root of Apps$ effectively makes the S: driver non-browsable. Unlike SQL server, where the database engine entirely masks the SQL database file structure so that the user has no rights to the actual SQL file folders, Access requires that the user have read/write access to the location of the Access front- and back-end files. By not allowing read, only traverse, of D:\Apps (the root of the S: drive), it keeps curious users from exploring their way to the file and accidentally moving or deleting either the front- or back-end files. Instead, I supply a shortcut directly to S:\MyAppFolder\MyAccessApp.accde. (The users have Access runtime installed so they can run the app).

Disclaimer: I know this is not absolute protection, so anyone goes off on a tangent about how someone could look at the properties of the shortcut and get there anyway, don't bother; absolute protection is not my goal nor the problem here. The fact is that these particular users might be prone to clicking on the S: drive in Windows Explorer and poking around but will probably never think to look at a shortcut, copy the target, and paste it into Explorer or Run. This is just a little "out of sight, out of mind" protection, which in my experience over the last 25 years in this business, is a greatly overlooked and underutilized approach to the avoidance of accidental and nuisance problems.

This has worked perfectly for years without any hitch on Windows 7. But as soon as we went to Windows 10, the first time (after each computer login) that a non-admin user double-clicks the shortcut, the user gets an error indicating, "The item 'MyAccessApp.accde' that this shortcut refers to has been changed or moved...Do you want to delete this shortcut.". If the user answers, "No", the user can just double-click the shorcut again, and the app opens fine. This persists until next computer logoff/logon.

Alternatively, if the user logs onto the computer, then right-clicks the shortcut, then Open File Location, the location opens in Windows Explorer. The user can then close the Windows Explorer and open the program without any denial. I have verified that things still work correctly on Windows 7 immediately upon computer logon, but that on at least two Windows 10 computers and two different domain users, it fails until it fails once or they go to the path once.

So it seems that the user has to access the read/write downline folder once before the user can actually open a shortcut to a file there. What is it about Windows 10 that requires the user to invoke a manual traverse before the shortcut-based traverse will work?

Answer 1

I found the problem, although I am not sure why it caused this particular behavior. In troubleshooting something else, I had made an adjustment to a login script that resulted in a .cmd file being called from a UNC path just before (instead of after) the particular drive was mapped, and this must have delayed or otherwise messed up something in the mapping. My application is on the S: drive, but the .cmd file below (not related to this application) was called before the S: drive is mapped.

It looked like this:

@Echo off
net use I: /delete
net use I: \MyServerName\Shared$ /persistent:no
\MyServerName\Shared$\MyCmdFile.cmd [moved this line to the end and used map instead of UNC]
net use S: /delete
net use S: \MyServerName\Apps$ /persistent:no
exit

My login script looks like this now; I moved the .cmd to be after the last net use (S: drive mapping) and replaced the UNC path with the previously-mapped S: drive letter:

@Echo off
net use I: /delete
net use I: \MyServerName\Shared$ /persistent:no
net use S: /delete
net use S: \MyServerName\Apps$ /persistent:no
I:\Shared$\MyCmdFile.cmd [moved from above and used drive letter instead of UNC]
exit

Now my app opens on the first try.