You are viewing limited content. For full access, please sign in.

Question

Question

Windows Users in a Repository Group are unable to see folders that the Repository Group has rights to see

asked on September 19, 2018

Hello,

 

We have a customer that created a Repository Group and gave the Group permissions to a LF Folder in the Repository, that allows them rights to see that folder and sub-folders and documents, and have edit rights to those folders.

She added 4 Users and only one can see the main folder and sub-folders, the other 3 can only see the top-folder.

They are not in any other Repository Group with limited access nor are their user accounts limited in scope.

Steps we tried:

  1. Delete the Group from the folder and add it back- No Luck only the one user could see it still everything
  2. Delete one of the affected users from the group and add them back- No Luck
  3. Customer added another user to the group and this user can see the folder and sub-folders

 

Not sure where else to look.

Thanks,

Jeff Curtis

 

0 0

Replies

replied on September 19, 2018

They have to log out and then back in before the new security applies to their account.

0 0
replied on September 20, 2018

Thanks Chad,

 

Had Customer do this and still not able to see sub-folders.

Jeff

0 0
replied on September 20, 2018

When viewing the access rights of one of these subfolders, click the Effective Rights tab. This allows you to select the user and verify they have access, in the event they are somehow denied from another group or configuration.

0 0
replied on September 25, 2018

Hello Chad,

We checked the effective permissions and it was showing blank.

We confirmed:

1. User is no other group or restricted by another folder in the folder structure

2. We removed the user from the Group and gave the user rights to the folder and sub-folders and files. Still could not see the sub-folders.

3. Deleted the user and add them back in, re-added to the group.  We saw the effective permissions were now showing, but user was still unable to see the sub-folders and interestingly we checked the effective permissions again and they were not longer showing access.

I am wonder if this is a Support Case now.

Thanks,

Jeff Curtis

0 0
replied on September 25, 2018

What happens if you create a new top level folder, give them access to that folder, then create a subfolder in your new folder, give them access, and repeat this process a few times.

If it works, there must be some difference between the new folder tree and the one your having the problem with. I would be trying to determine what that difference is.

0 0
replied on September 25, 2018

Thanks Chad...Here is the interesting thing, they have two sub-folders.  One of the folders they explicitly deny access to for this group.  The other folder they give this group almost full rights.

 

I have tested this on my end and when the test user tried to access the folder with explicit deny, no access.  I can access the other sub-folder with no issue.

 

Only thing different for me, I have everyone set with view/edit at the top-level of the repository.  Customer does not have everyone listed.  Not sure if that would make a difference or not.

 

Thanks for the help.

 

Jeff Curtis

0 0
replied on September 26, 2018

The denied subfolder is irrelevant to the problem though. The problem is that they can't get into a folder they should have rights to. There could be a million alternative folders they are denied to, as long as those folders are not a parent folder, then they are orthogonal, independent, and unable to interfere in any way.

0 0
replied on September 26, 2018

Thanks Chad!!

I figured the denied setting had nothing to do with it, but wanted to check.

We are still looking at settings.

Jeff Curtis

0 0
replied on September 26, 2018 Show version history

Start at the top and work down looking at the access rights on each folder.  Are there any groups and/or user (LF or Windows) add to the folder(s) with explicit denies?  To be blocked from a folder where they have explicitly or inherited read and browse, either their user and/or a group they are a member of must have an explicit deny.  We try to avoid explicit denies as much as possible to avoid unintended denial of access.

Also, check the scopes of the groups and/or users where the read and browse are granted.  If the scope has been changed, they may not be granted access where you think they are.

0 0
replied on September 28, 2018

Note that if you are using the 10.2 web or Windows Client or later, you can select a specific right in the effective rights dialog and click a link at the bottom of the dialog to be told exactly why the system thinks you do or do not have rights to this entry for the specified user. This is very helpful for troubleshooting these types of scenarios without having to crawl through the tree one by one. 

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.