Solved Network Sharing Folder With Traverse Permissions (1 Viewer)

Pac-Man

Active member
Local time
Today, 19:36
Joined
Apr 14, 2020
Messages
408
Hello,

I apologies in advance if it is not the right category/place to ask this question but I've been looking for this for on Google but failed to find any solution. My purpose is to avoid people seeing backend folder's contents or copying other files into backend folder.

I've heard somewhere that while sharing a folder for backends, we can adjust its settings so that people with link to file can access those files (like frontend can access backend) but people cannot navigate through the folder. It's something called traverse permissions.

How do I set it up? I usually share a folder and give everyone read/write rights so that user can access my shared contents and place their files which they want to share with me. I did exactly the same for backend shared folder. If I don't give everyone these rights, frontend cannot work. What's the best way to do that?

Update: Let me explain my folder structure a bit (which was left when posting the question). I've a folder named as Frontend and it has different files, folders and backend db's inside it. I share this Backend folder and also tick the checkbox which says something like apply same permissions to children items and folders.

Best Regards,
Abdullah
 
Last edited:

theDBguy

I’m here to help
Staff member
Local time
Today, 07:36
Joined
Oct 29, 2018
Messages
21,357
Hi. Not in front of a computer right now, but you're on the right track. If you go to the Security tab when sharing a folder, you might click on the Advance button to see the Traverse permission.

PS. Be aware though, all it means is users won't be able to navigate to this folder by "browsing" but would still be able to open the folder by using the full path, which is not that hard to find out from the front end.
 

Pac-Man

Active member
Local time
Today, 19:36
Joined
Apr 14, 2020
Messages
408
Hi. Not in front of a computer right now, but you're in the right track. If you go to the Security tab when sharing a folder, you might click on the Advance button to see the Traverse permission.
I tried by checking and unchecking traverse permissions of everyone in security settings but I can still navigate through the shared folder and contents of shared backend folder.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 07:36
Joined
Oct 29, 2018
Messages
21,357
I tried by checking and unchecking traverse permissions of everyone in security settings but I can still navigate through the shared folder and contents of shared folder.
Probably because you are the "owner" of the folder. Have another user try it.
 

Pac-Man

Active member
Local time
Today, 19:36
Joined
Apr 14, 2020
Messages
408
Probably because you are the "owner" of the folder. Have another user try it.
I'm not on domain network Sharing do every PC have it's local users. I tried other PC (with different local user) on the network to check and it can navigate.

Secondly, should I check or uncheck traverse permissions to prevent users from navigation through the folder?

Moreover, let's I've a folder named as Frontend and it had different files, folders and backend inside it. I share this Backend folder and also tick the checkbox which something like apply same permissions to children items and folders.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 07:36
Joined
Oct 29, 2018
Messages
21,357
I'm not on domain network Sharing do every PC have it's local users. I tried other PC (with different local user) on the network to check and it can navigate.

Secondly, should I check or uncheck traverse permissions to prevent users from navigation through the folder?

Moreover, let's I've a folder named as Frontend and it had different files, folders and backend inside it. I share this Backend folder and also tick the checkbox which something like apply same permissions to children items and folders.
I think the explanation here makes sense.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 09:36
Joined
Feb 28, 2001
Messages
26,999
Here is a problem I see. For a native Access back-end file, you must have MODIFY-level permissions on the folder and the files therein or you would be unable to manipulate the lock file according to Access operational protocols. If you cannot manipulate the lock file, then for your session, Access opens the DB file in Read-Only mode unless it can get an Exclusive lock - which makes it single-user-at-a-time. So you sacrifice the ability to share the BE file if you strip away needed permissions.

If you wanted to store information in separate files in the same folder as the BE or in sub-folders thereof, you would still need Read & Write on that folder in order for Access to do anything. (This is because if YOU launch Access, it runs as YOU.) If you turned off that folder's permissions such that you couldn't see anything with manual browsing, then Access could not see it either.

But there is a bit more to it than that. If a person has READ permissions then they don't need TRAVERSE. That is a special permission that double-dips as "Execute" for executable images. Having it means even if you DON'T have READ permission, you can identify folders in order to get through the restricted folder. You just can't do a command-line "DIR" command or browse to that folder and see its contents. Most often, you use TRAVERSE when you have a "sneaky" Mount Point or a cross-directory Icon that isn't pointing to a top-level folder on the disk, but rather is pointing somewhere two or three folders deep in that disk's folder structure.

The REAL problem (from the way you described your setup) is that you have possibly chosen a bad place for your back-end file if it isn't a "leaf" node (end-node?) in the directory tree. If you have nothing "beneath" you in the directory tree then Traverse has no practical meaning. Ideally, you get the most protection by having nothing else in the folder but the Access-related files. Then there is no problem with permission interitance and there is nothing to traverse.
 

Pac-Man

Active member
Local time
Today, 19:36
Joined
Apr 14, 2020
Messages
408
I think the explanation here makes sense.
Thanks a lot for the link. From the link, I feel that I am setting permissions incorrect. Instead of setting traverse to the top folder, I should set it to the lower folders in hierarchy and restrict permissions to only read or no permissions for the top folder. Let me check and I'll report back here in case of problem.

The REAL problem (from the way you described your setup) is that you have possibly chosen a bad place for your back-end file if it isn't a "leaf" node (end-node?) in the directory tree. If you have nothing "beneath" you in the directory tree then Traverse has no practical meaning. Ideally, you get the most protection by having nothing else in the folder but the Access-related files. Then there is no problem with permission interitance and there is nothing to traverse.
Thanks for such detailed reply. My backend is placed in the lower most folder in hierarchy and nothing else is placed in it. But I wanted to restrict users navigate in the top folder. And yes I do have to give R/W permissions to everyone for frontend to operate normally and to prevent db opening in read only mode.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 09:36
Joined
Feb 28, 2001
Messages
26,999
Unfortunately, you will often run into problems by overly restricting top-level folders. The REAL problem here is the absence of a formal domain infrastructure, which would allow you to create a group identifier and then grant it to the users of your DB. Therefore, you don't have the full set of tools that are normally in a shared-environment toolkit. This is NOT meant as a negative statement; you have what you have.

You have a mine field here because in the absence of everyone having a domain environment, that means that each person has admin rights on their own machine. Further, their personal (i.e. Windows internal) user identifiers mean nothing to the other machines because those identifiers are in that case assigned locally and darned near randomly when the user account is created. There is no central repository (Active Directory) facility in which to store the user identifiers.

If you are going to implement protections in this environment then the best way to proceed is to have a top-level folder and perhaps a second-level folder (with a short name to make name-typing easier) before putting your Access files in a third-level folder. Then EACH USER must have a "remote" account on the machine holding the back end files. After that step, you can do something that is totally wrong in a domain environment but absolutely necessary in a non-domain environment. You can assign individual user permissions on that 2nd-level folder for TRAVERSE, but DENY READ for all other uses except the administrator, machine's owner (who would probably be in the administrator group anyway), and SYSTEM. NEVER EVER deny system access to anything. First, you can't because SYSTEM has BYPASS privilege and can ignore the "DENY" and second the file system needs to be able to see everything in order to FIND the permission entries in order to apply them.

IF you are going this way, then when you prepare to distribute copies of the front-end file to your users, your computers on the network MUST have unique names. That is because your best bet is to make the FE link back to the correct BE file using URS mapping rather than drive-letter mapping, that that would include the explicit path name to the BE from the device in question. On my system that might look like

Code:
\\MYXPS\Device\HarddiskVolume1\top-folder\next-folder\target-folder

And you can get that name by going to the command prompt, type SYSTEMINFO, and look for the Boot Device.

Or you can try for the WMI name (might be shorter) by again going to the command prompt. Type wmic diskdrive list brief /format:list and then using the name you see for your hard drive. In my case the relevant output is

Code:
Caption=ADATA SU760
DeviceID=\\.\PHYSICALDRIVE0
Model=ADATA SU760
Partitions=2
Size=1024203640320

Either the SYSTEMINFO boot device name or the WMIC device ID will be correct for building that info.

Note that if you at least have Windows "Professional" edition on your machines you might have access to LUSRMGR, which would give you a way to create local groups and to assign membership thereof. If you are stuck on Win10 Home then LUSRMGR will not run. There is also the NET command (a COMMAND LINE option) to create a LOCALGROUP and assign membership thereof. I have not tried this approach myself but here is a link to documentation on the NET command.

 

Pac-Man

Active member
Local time
Today, 19:36
Joined
Apr 14, 2020
Messages
408
Unfortunately, you will often run into problems by overly restricting top-level folders. The REAL problem here is the absence of a formal domain infrastructure, which would allow you to create a group identifier and then grant it to the users of your DB. Therefore, you don't have the full set of tools that are normally in a shared-environment toolkit. This is NOT meant as a negative statement; you have what you have.

You have a mine field here because in the absence of everyone having a domain environment, that means that each person has admin rights on their own machine. Further, their personal (i.e. Windows internal) user identifiers mean nothing to the other machines because those identifiers are in that case assigned locally and darned near randomly when the user account is created. There is no central repository (Active Directory) facility in which to store the user identifiers.

If you are going to implement protections in this environment then the best way to proceed is to have a top-level folder and perhaps a second-level folder (with a short name to make name-typing easier) before putting your Access files in a third-level folder. Then EACH USER must have a "remote" account on the machine holding the back end files. After that step, you can do something that is totally wrong in a domain environment but absolutely necessary in a non-domain environment. You can assign individual user permissions on that 2nd-level folder for TRAVERSE, but DENY READ for all other uses except the administrator, machine's owner (who would probably be in the administrator group anyway), and SYSTEM. NEVER EVER deny system access to anything. First, you can't because SYSTEM has BYPASS privilege and can ignore the "DENY" and second the file system needs to be able to see everything in order to FIND the permission entries in order to apply them.

IF you are going this way, then when you prepare to distribute copies of the front-end file to your users, your computers on the network MUST have unique names. That is because your best bet is to make the FE link back to the correct BE file using URS mapping rather than drive-letter mapping, that that would include the explicit path name to the BE from the device in question. On my system that might look like

Code:
\\MYXPS\Device\HarddiskVolume1\top-folder\next-folder\target-folder

And you can get that name by going to the command prompt, type SYSTEMINFO, and look for the Boot Device.

Or you can try for the WMI name (might be shorter) by again going to the command prompt. Type wmic diskdrive list brief /format:list and then using the name you see for your hard drive. In my case the relevant output is

Code:
Caption=ADATA SU760
DeviceID=\\.\PHYSICALDRIVE0
Model=ADATA SU760
Partitions=2
Size=1024203640320

Either the SYSTEMINFO boot device name or the WMIC device ID will be correct for building that info.

Note that if you at least have Windows "Professional" edition on your machines you might have access to LUSRMGR, which would give you a way to create local groups and to assign membership thereof. If you are stuck on Win10 Home then LUSRMGR will not run. There is also the NET command (a COMMAND LINE option) to create a LOCALGROUP and assign membership thereof. I have not tried this approach myself but here is a link to documentation on the NET command.

Thank you so much for such detailed reply. I can't thank you enough for putting so much effort in explaining the subject.

Now coming to my case, even though I have to make about 20 user accounts on backend PC but it seems kind nice to have situation like domain setup (i.e. every user has his own user name password). You said in your reply:
You can assign individual user permissions on that 2nd-level folder for TRAVERSE, but DENY READ for all other uses except the administrator, machine's owner
I take it as traverse rights are sufficient for split database to work. We may not need any other extra permissions like read and write.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 09:36
Joined
Feb 28, 2001
Messages
26,999
You are looking for TWO things - you want to protect something from casual browsing and poking around AND you want to use something that is being protected. Those two requirements are not possible simultaneously without a little extra complexity in the setup.

To protect something, you have no overarching domain to impose group security so you must use local permissions. Therefore in a directory infrastructure, if you want to stop people from seeing the contents of a folder, you have to hide behind another folder. But blocking a top-level folder from being scanned can cause people to have difficulties in using the folder, particularly if anything else is in it besides your files.

So, on the machine that is the host of the back end file, create a separate top-level folder that has as its ownership the account (on THAT machine) of whoever is the project maintainer. (I'm guessing that is you?) This 1st-level folder should be a normal folder that for other users could have no worse than READ (only) for Authenticated Users. This prevents folks from diddling with permissions. This same machine, because you can't create group identifiers, must have all 20 of your potential app user accounts on it. On this machine, the accounts CANNOT be ADMIN-class. They must be USER class accounts.

Now in that top-level folder, create a 2nd-level folder using a short name so it will be easy to type. Give those 20 users TRAVERSE permissions at the 2nd level folder. If you can do that, you must be working on Windows Professional because Windows Home uses simplified permissions and makes it a pain to apply fine-grain permissions. Once you have granted the 20 users TRAVERSE for that folder, add entries to allow OWNER and SYSTEM and ADMINISTRATOR to have FULL CONTROL permissions. Then add one last entry, DENY READ, for Anyone. The order is important. The "DENY" MUST be last in declaration sequence because permissions are tested in the order they are defined. The 2nd-level folder is your "blocker" that will keep out users other than the 20 you intended to allow in. BUT you cannot work in that folder if you only have TRAVERSE permissions. So, inside that 2nd level folder, ...

Create a 3rd-level folder to hold your database files. THAT folder should grant the usual FULL CONTROL to OWNER, SYSTEM, and ADMINISTRATOR. You should then grant MODIFY to your 20 users. Don't bother to diddle with the fine-grained permissions - the MODIFY "broad-brush" setting is what you need. THIS is where your app will reside and work. Again, if you wish to put up another roadblock you can put a DENY READ for All Users provided that is the last entry in the permissions list.

The last leg of this is to remember that your users CANNOT browse to find the files. TRAVERSE means you can see that there is a directory there but you cannot see what is in it. So Windows Explorer will not work. You MUST include the full path in any file references in order to get to where the files are located. This means full file paths in icons that might reach into the shared folder to get a new copy of the FE file and full paths leading to BE tables via the Linked Table Manager. Remember that because of the protection of the 2nd level folder, BROWSING WILL NOT WORK.
 

Galaxiom

Super Moderator
Staff member
Local time
Tomorrow, 01:36
Joined
Jan 20, 2009
Messages
12,849
I put Access backends on a hidden share. Simply append a $ to the end of the sharename when you set it up.
You can still link it in Access to this name or browse to it if you know the name.

However we also prevent ordinary users browsing of UNC paths so they can't find the folder in File Explorer.
Their applications can still find the share.
 

Pac-Man

Active member
Local time
Today, 19:36
Joined
Apr 14, 2020
Messages
408
You are looking for TWO things - you want to protect something from casual browsing and poking around AND you want to use something that is being protected. Those two requirements are not possible simultaneously without a little extra complexity in the setup.

To protect something, you have no overarching domain to impose group security so you must use local permissions. Therefore in a directory infrastructure, if you want to stop people from seeing the contents of a folder, you have to hide behind another folder. But blocking a top-level folder from being scanned can cause people to have difficulties in using the folder, particularly if anything else is in it besides your files.

So, on the machine that is the host of the back end file, create a separate top-level folder that has as its ownership the account (on THAT machine) of whoever is the project maintainer. (I'm guessing that is you?) This 1st-level folder should be a normal folder that for other users could have no worse than READ (only) for Authenticated Users. This prevents folks from diddling with permissions. This same machine, because you can't create group identifiers, must have all 20 of your potential app user accounts on it. On this machine, the accounts CANNOT be ADMIN-class. They must be USER class accounts.

Now in that top-level folder, create a 2nd-level folder using a short name so it will be easy to type. Give those 20 users TRAVERSE permissions at the 2nd level folder. If you can do that, you must be working on Windows Professional because Windows Home uses simplified permissions and makes it a pain to apply fine-grain permissions. Once you have granted the 20 users TRAVERSE for that folder, add entries to allow OWNER and SYSTEM and ADMINISTRATOR to have FULL CONTROL permissions. Then add one last entry, DENY READ, for Anyone. The order is important. The "DENY" MUST be last in declaration sequence because permissions are tested in the order they are defined. The 2nd-level folder is your "blocker" that will keep out users other than the 20 you intended to allow in. BUT you cannot work in that folder if you only have TRAVERSE permissions. So, inside that 2nd level folder, ...

Create a 3rd-level folder to hold your database files. THAT folder should grant the usual FULL CONTROL to OWNER, SYSTEM, and ADMINISTRATOR. You should then grant MODIFY to your 20 users. Don't bother to diddle with the fine-grained permissions - the MODIFY "broad-brush" setting is what you need. THIS is where your app will reside and work. Again, if you wish to put up another roadblock you can put a DENY READ for All Users provided that is the last entry in the permissions list.

The last leg of this is to remember that your users CANNOT browse to find the files. TRAVERSE means you can see that there is a directory there but you cannot see what is in it. So Windows Explorer will not work. You MUST include the full path in any file references in order to get to where the files are located. This means full file paths in icons that might reach into the shared folder to get a new copy of the FE file and full paths leading to BE tables via the Linked Table Manager. Remember that because of the protection of the 2nd level folder, BROWSING WILL NOT WORK.
It's so kind of you to explain complete process of setting up. It completely fullfills what I want to achieve. Thank you so much again.
I put Access backends on a hidden share. Simply append a $ to the end of the sharename when you set it up.
I didn't know about hiding a shared folder. Thanks for the tip. Will try that too.
 
Last edited:

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 09:36
Joined
Feb 28, 2001
Messages
26,999
Galaxiom's method actually dovetails with my method because the hidden share could point to the 3rd-level folder that is protected behind that really tightly restricted 2nd level folder I described. It would fulfill the requirement of having an explicit path through the TRAVERSE-only folder. That way you not only hide the 3rd level folder from casual browsing but you also hide that "link" to it by having the path as part of the hidden share declaration.
 

Pac-Man

Active member
Local time
Today, 19:36
Joined
Apr 14, 2020
Messages
408
Thanks a lot for your time and reply. I'll check both ways separately and together. Which unfortunately I couldn't till now due to certain reasons. Thanks again.
 

kokowawa

Member
Local time
Today, 16:36
Joined
May 11, 2020
Messages
51
You are looking for TWO things - you want to protect something from casual browsing and poking around AND you want to use something that is being protected. Those two requirements are not possible simultaneously without a little extra complexity in the setup.

To protect something, you have no overarching domain to impose group security so you must use local permissions. Therefore in a directory infrastructure, if you want to stop people from seeing the contents of a folder, you have to hide behind another folder. But blocking a top-level folder from being scanned can cause people to have difficulties in using the folder, particularly if anything else is in it besides your files.

So, on the machine that is the host of the back end file, create a separate top-level folder that has as its ownership the account (on THAT machine) of whoever is the project maintainer. (I'm guessing that is you?) This 1st-level folder should be a normal folder that for other users could have no worse than READ (only) for Authenticated Users. This prevents folks from diddling with permissions. This same machine, because you can't create group identifiers, must have all 20 of your potential app user accounts on it. On this machine, the accounts CANNOT be ADMIN-class. They must be USER class accounts.

Now in that top-level folder, create a 2nd-level folder using a short name so it will be easy to type. Give those 20 users TRAVERSE permissions at the 2nd level folder. If you can do that, you must be working on Windows Professional because Windows Home uses simplified permissions and makes it a pain to apply fine-grain permissions. Once you have granted the 20 users TRAVERSE for that folder, add entries to allow OWNER and SYSTEM and ADMINISTRATOR to have FULL CONTROL permissions. Then add one last entry, DENY READ, for Anyone. The order is important. The "DENY" MUST be last in declaration sequence because permissions are tested in the order they are defined. The 2nd-level folder is your "blocker" that will keep out users other than the 20 you intended to allow in. BUT you cannot work in that folder if you only have TRAVERSE permissions. So, inside that 2nd level folder, ...

Create a 3rd-level folder to hold your database files. THAT folder should grant the usual FULL CONTROL to OWNER, SYSTEM, and ADMINISTRATOR. You should then grant MODIFY to your 20 users. Don't bother to diddle with the fine-grained permissions - the MODIFY "broad-brush" setting is what you need. THIS is where your app will reside and work. Again, if you wish to put up another roadblock you can put a DENY READ for All Users provided that is the last entry in the permissions list.

The last leg of this is to remember that your users CANNOT browse to find the files. TRAVERSE means you can see that there is a directory there but you cannot see what is in it. So Windows Explorer will not work. You MUST include the full path in any file references in order to get to where the files are located. This means full file paths in icons that might reach into the shared folder to get a new copy of the FE file and full paths leading to BE tables via the Linked Table Manager. Remember that because of the protection of the 2nd level folder, BROWSING WILL NOT WORK.
hello @The_Doc_Man , the method above looks the best solution plus the hidding the network folder by $ that @Galaxiom suggested,

as i am not really expert with network and permissions , would you please be kind and make a tutorial video for this method that i can try to me app .

regards
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 09:36
Joined
Feb 28, 2001
Messages
26,999
Sorry but I have no way to make a decent video. Or indecent, for that matter. I'm retired and don't have fancy hardware or software on my system to do that. All I can say is that you should be able to find instructions via web searching.
 

kokowawa

Member
Local time
Today, 16:36
Joined
May 11, 2020
Messages
51
Sorry but I have no way to make a decent video. Or indecent, for that matter. I'm retired and don't have fancy hardware or software on my system to do that. All I can say is that you should be able to find instructions via web searching.
no problem ofcours , thank you anyway . i will try to follow your instructions above and if i didnt get it i will search the web.
 

Users who are viewing this thread

Top Bottom