Question

Administrator override to delete a folder in Laserfiche even if you do not have rights to all child objects

Laserfiche Administration

Updated February 1

asked on January 31

We have a client with a folder in their repository they would like to delete but they are getting an Access Denied message.

They have the Manage Security override privilege allowing them to change the access rights but the access denied messages does not offer any information on which child object their being denied on. There are thousands of child objects.

Is there another way to delete this folder?

0 0

Answer

SELECTED ANSWER

replied on February 1 • Show version history

The spreadsheet will use Yes to indicate that a right has been effectively granted, but rather than No if it is not, it uses three dashes (---). Try searching for those and seeing if something comes up.

If it doesn't, then the issue is probably not entry access rights and might be something else that affects the ability to delete. The things that come immediately to mind are a security tag that you don't have access to (you can check for this by logging in as a user with the Manage Tags privilege and seeing if there are security tags in your repository), or a records management issue (items under hold or cutoff can't be deleted).

Let me know whether this helps!

2 0

Replies

replied on February 1 • Show version history

The most straightforward way to troubleshoot this would be to run a user effective access right report. Select the folder that you want to delete and go to the more actions button in the web client (the one with three vertical dots) or the Tasks menu in the Windows client. Pick Generate Report, and then select User Effective Access Rights Report. Put in your user name and then add the rights you want to run the report on (I usually just select all rights, which means that you can find any weird quirkiness).

What it will produce is a spreadsheet that looks something like this:

From there, you can determine what documents/folders you don't have sufficient access to. (It will show not only the folder you selected, but all its child documents, subfolders, their documents, etc., all the way down the line.) You can then go to the topmost item that you don't have delete rights for, and check the security on it to see what you need to grant yourself to be able to delete it.

3 0

View 2 previous replies

replied on February 1

This is a cool feature. I ran this report for my user account, Admin, with everything checked.

I then used Excel to search all security columns for the word "No" and not a single row exists. It is all Yes, all the way down.

Just to clarify the message we receive is below, I assumed since I have access to the folder I am trying to delete "zOLDFinance Company Access" that it must be regarding a child object. Am I reading this message wrong?

LFSO:
Call Stack: (Exception)
CLFProgress::ThrowLastError
Additional Details:
HRESULT: 0xc0042335 (CLFProgress::ThrowLastError, LFProgress.cpp:528)
(LFSO/11.0.2102.9)
LF.exe (11.0.2102.183):
Call Stack: (Current)
CFolderListView::DeleteCurrentFolder
CFolderTreeView::OnFileDelete
Additional Details:
Exception: 0xc0042335 [9013] (Permission denied.) (CFolderListView::DeleteCurrentFolder at FolderListView.cpp:448)

0 0

replied on February 1

Never realized that report existed - good to know!

1 0

SELECTED ANSWER

replied on February 1 • Show version history

Let me know whether this helps!

2 0

replied on February 1

It was a security tag. I was only able to check if they had any security tags at all, then just give myself all of them and then I could delete. There was no other way to know where the tag was set or why it was blocking my access.

I am confused as to what the advantage of using a security tag over access rights would be and why they would have precedence over access rights since access rights is where we go to see who has access.

Thanks for all the info though, at least it allowed for deleting these files!

1 0

replied on February 1 • Show version history

Glad it helped!

In general, I agree: if you can accomplish what you want to accomplish purely with entry access rights, it's a good idea to do so rather than using security tags, for exactly the reason you encountered--it's a lot easier to troubleshoot a security issue if you only need to check one set of access controls.

That said, the reason that security tags exist (and the reason that they supersede entry access rights, in the sense that even someone with the Manage Entry Access privilege can't see a document with a security tag unless they have been granted that tag) is for exception cases where you can't accomplish what you need purely with entry access rights. This may be because a document is being moved between multiple folders; it could inherit different rights from folder to folder if you're relying purely on entry access rights, but the security tag stays attached to it wherever it is moved. Alternately, a site might need to conceal certain documents even from users with the Manage Entry Access privilege. Because of this, security tags, and their precedence over entry access rights, are required for certain kinds of regulatory compliance (for example, I know that they were first introduced in Laserfiche to allow us to gain our DoD 5015.2 compliance).

But again, I generally feel that if you don't need to use a security tag to accomplish whatever you're trying to do (or you aren't bound by a particular regulation to use one), you probably shouldn't use one, because it's easier to maintain a system with a minimum of security exception cases.

1 0

replied on January 31 • Show version history

Wow, I guess they have inheritance turned off on the child folders. In that case, I'd write a workflow to add the rights to all child folders.

0 0

View 6 previous replies

replied on January 31

If you are denied access, regardless of your inherited rights you will still be denied.

Their licensing plan does not include any workflow capabilities.

0 0

replied on January 31

I would say Workflow too. Without that, I would just start working through subfolders, trying to find ones that can be deleted versus ones that cannot. Kind of tackle the problem iteratively.

Or maybe you could create a new role (maybe just temporarily) and add it to a user with no other roles. Grant permission for that role to that top folder and all of its children. Unless the denial is set to the Everyone object, this new user with new role and no other roles, should have permission to the full folder.

2 0

replied on January 31 • Show version history

Good idea, just tried creating a new user and adding it rights to the root of the folder, still denied somewhere. But this could be due to removing inheritance. Ultimately we need a way to override.

It is impossible to implement an iterative solution. For example we went into sub folders verifying full access to each one all the way until we just found files. Then we tried to delete the folder which we have full access to and found that a specific file is denied. There are hundreds of files.

Edit: And to clarify, each time we do this we are just told that some file is denied, not which file. I guess it would be a security vulnerability to tell us which file, so there is no way to fix the file that is denying us access to the folder.

0 0

replied on January 31

If they are on at least version 10.3, you can search for entries that have rights to delete the entry granted or denied using the following search syntax - just replace FOLDERPATH with the path of the top folder they want to delete. It should return every folder and document that has rights granted or denied to delete entries.

{LF:LOOKIN="FOLDERPATH"} &
{LFACE:rights = "del*"}

I did some tests in my test environment, and confirmed the same behavior trying to delete the folder when a document several levels deep had the permission denied. Then I tested this search, and it found the specific document that I had denied the permission on, and another I had granted the permission on.

0 0

replied on January 31 • Show version history

I just tested it and get 0 results. But if I deny myself delete on any object in the folder it does come back in a search. Is it covering the fact that maybe I just do not have rights to delete at all?

0 0

replied on January 31 • Show version history

I believe that search would be looking for rights specifically granted or specifically denied. I do not believe that it would be returning rights that are just not assigned either way.

Darn, that's more complicated if you just have a ton of stuff marked to not inherit permissions.

0 0

replied on January 31

I can't find syntax to do an LFACE search to identify entries with the inheritenace turned off. Either there isn't an option for that, or it isn't in the documentation.

Frustratingly, the documentation I have about the LFACE search is in a PDF named Advanced Search Syntax 10.3 - it doesn't appear to be included in the Laserfiche User Guide version 11 (section titles don't give a hint about that topic, and nothing comes up when I search LFACE).

0 0

replied on January 31

I think they really need the master override here. Interesting that they found a way to make a folder impossible to delete. It does not even delete the documents I do have rights to, if there is one single entry I don't have rights to, the entire op is canceled.

In my access rights trainings I teach everyone not to remove inheritance, but I am fighting against an industry of developers who keep putting the switch in their software with no warning, including Microsoft. It breaks backup systems, audits, migrations, and racks up costs in IT support.

1 0

replied on January 31

One more idea...

If you have access to the repository database, a query like the one below should be able to pinpoint the entries that have any permissions set and/or have inheritence turned off. Be aware that this is kind of a beast to run, especially on a large repository. It should work up to 12 levels deep in the folders. If you know none of the folders are that deep, you can delete some of the JOINS and the subsequent parts of the WHERE statement, to get it to be more efficient. If there could be more than 12 levels, you'll need to add more to the JOINS and update the WHERE statement.

Of course, that won't resolve the issue, but now you have a list of entry IDs that could be used in search syntax like this:

{LF:ID=1} | 
{LF:ID=2} | 
{LF:ID=3} | 
{LF:ID=4}

To run the query, replace the 99999 with the entry ID of your top folder. And replace [LaserficheRepositoryDatabaseGoesHere] with the actual database name.

USE [LaserficheRepositoryDatabaseGoesHere]
DECLARE @EntryID BIGINT;
SET @EntryID = 99999;
SELECT
  A.[tocid] AS [entry_id],
  A.[name]
FROM [toc] AS A
LEFT JOIN [toc] AS B ON B.[tocid] = A.[parentid]
LEFT JOIN [toc] AS C ON C.[tocid] = B.[parentid]
LEFT JOIN [toc] AS D ON D.[tocid] = C.[parentid]
LEFT JOIN [toc] AS E ON E.[tocid] = D.[parentid]
LEFT JOIN [toc] AS F ON F.[tocid] = E.[parentid]
LEFT JOIN [toc] AS G ON G.[tocid] = F.[parentid]
LEFT JOIN [toc] AS H ON H.[tocid] = G.[parentid]
LEFT JOIN [toc] AS I ON I.[tocid] = H.[parentid]
LEFT JOIN [toc] AS J ON J.[tocid] = I.[parentid]
LEFT JOIN [toc] AS K ON K.[tocid] = J.[parentid]
LEFT JOIN [toc] AS L ON L.[tocid] = K.[parentid]
LEFT JOIN [toc] AS M ON M.[tocid] = L.[parentid]
WHERE 
  A.[tocid] = A.[acl_tocid]
  AND (
    A.[tocid] = @EntryID
    OR B.[tocid] = @EntryID
    OR C.[tocid] = @EntryID
    OR D.[tocid] = @EntryID
    OR E.[tocid] = @EntryID
    OR F.[tocid] = @EntryID
    OR G.[tocid] = @EntryID
    OR H.[tocid] = @EntryID
    OR I.[tocid] = @EntryID
    OR J.[tocid] = @EntryID
    OR K.[tocid] = @EntryID
    OR L.[tocid] = @EntryID
    OR M.[tocid] = @EntryID
  )

1 0

You are not allowed to follow up in this post.

Question

Question

Administrator override to delete a folder in Laserfiche even if you do not have rights to all child objects

Answer

Replies

Sign in to reply to this post.