You do not have permission to access this library

Hi,

i still have some problems since the file Locking mechanism is in place. We randomly get “You do not have permission to access this library” and the client drops the synchronisation. Only a comnplete resync helps in this case.

Server: Pro 5.1.10
Client: Always around 5.1.x

[08/31/16 08:06:56] sync-mgr.c(660): Repo 'A 8' sync state transition from 'downloading' to 'synchronized'. [08/31/16 08:06:56] sync-mgr.c(1479): Removing blocks for repo A 8(84be3ff3). [08/31/16 08:06:57] sync-mgr.c(660): Repo 'A 8' sync state transition from 'synchronized' to 'committing'. [08/31/16 08:06:57] repo-mgr.c(1984): Failed to stat Team/Personales/Name/2016/B2720000: No such file or directory. [08/31/16 08:06:57] repo-mgr.c(1984): Failed to stat Team/Personales/Name/2016/B2720000: No such file or directory. [08/31/16 08:06:57] repo-mgr.c(3571): All events are processed for repo 84be3ff3-091b-49c5-a076-d600297cf2a3. [08/31/16 08:06:58] sync-mgr.c(660): Repo 'A 8' sync state transition from 'committing' to 'uploading'. [08/31/16 08:06:58] http-tx-mgr.c(3272): Upload with HTTP sync protocol version 1. [08/31/16 08:06:58] http-tx-mgr.c(1012): Transfer repo '84be3ff3': ('normal', 'init') --> ('normal', 'check') [08/31/16 08:06:58] http-tx-mgr.c(1012): Transfer repo '84be3ff3': ('normal', 'check') --> ('normal', 'commit') [08/31/16 08:06:58] http-tx-mgr.c(1012): Transfer repo '84be3ff3': ('normal', 'commit') --> ('normal', 'fs') [08/31/16 08:06:58] http-tx-mgr.c(1012): Transfer repo '84be3ff3': ('normal', 'fs') --> ('normal', 'data') [08/31/16 08:06:58] http-tx-mgr.c(1012): Transfer repo '84be3ff3': ('normal', 'data') --> ('normal', 'update-branch') [08/31/16 08:06:58] http-tx-mgr.c(3179): Bad response code for PUT https://sub.domain.tld/seafhttp/repo/84be3ff3-091b-49c5-a076-d600297cf2a3/commit/HEAD/?head=a936237d6617c482c07efebf600fd58be9d89805: 403. [08/31/16 08:06:58] http-tx-mgr.c(3395): Failed to update branch of repo 84be3ff3. [08/31/16 08:06:58] http-tx-mgr.c(1012): Transfer repo '84be3ff3': ('normal', 'update-branch') --> ('error', 'finished') [08/31/16 08:06:58] sync-mgr.c(728): Repo 'A 8' sync state transition from uploading to 'error': 'You do not have permission to access this library'.

Is there anything we can do to fix this?

bye Andre

Hi Andre,

we also had some customers with this problem. A reupload helped, but is not the best solution. Can you confirm that this only happens if the library is shared with other users? Interesting to know would be: Is the library directly shared to the user or in a group? If i remember right, the customer was using a group. Also: happens this to the user who shared the library or to the others?

Can you post the log entries about lock cleaning in seafile.log at the server side?

This library is shared in a group AND direct. (we switched from group sharing to direkt sharing since it is possible in the client)

Seafile.log from the past 2 days:

[08/30/2016 12:08:41 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 12:08:42 AM] filelock-mgr.c(938): 1 expired file locks are unlocked. [08/30/2016 01:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 02:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 03:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 04:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 05:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 05:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 06:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 06:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 07:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 07:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 08:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 08:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 09:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 09:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 10:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 10:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 11:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 11:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 12:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 12:08:42 PM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 01:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 01:08:42 PM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 02:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 02:08:42 PM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 03:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 03:08:42 PM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 04:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 04:08:42 PM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 05:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 05:08:42 PM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 06:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 06:08:42 PM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 07:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 07:08:42 PM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 08:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 08:08:42 PM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 09:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 09:08:42 PM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/30/2016 10:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/30/2016 10:08:42 PM] filelock-mgr.c(938): 1 expired file locks are unlocked. [08/30/2016 11:08:42 PM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 12:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 01:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 02:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 03:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 04:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 05:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 06:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 06:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/31/2016 07:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 07:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/31/2016 08:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 08:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/31/2016 09:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 09:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/31/2016 10:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 10:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked. [08/31/2016 11:08:42 AM] filelock-mgr.c(908): Cleaning expired file locks. [08/31/2016 11:08:42 AM] filelock-mgr.c(938): 0 expired file locks are unlocked.

You should ensure all the users are using >= 5.1.3 version, which fixes the auto locking issue.

On the server side, you can use shorter auto expire time for file locks. That way the locks can be cleaned up faster. Following the instructions at the end of this manual: http://manual.seafile.com/config/seafile-conf.html

I’m almost through to update all users. Only a couple left.

It is a pain in the a*** to update every client manually. We have about 60 external user at this point. It took me about two working days. We are Planning to migrate more and more users (150 is our plan).

It would be very helpfull if there is some kind of internal “rollout” where the client is updating itself. My users are real “non-techies”.

1 Like

Is it possible for you to use GPO to install clients on all windows computers? http://manual.seafile.com/config/desktop_customization.html

Only for a small part of our Users. Most of them are in their own “network”. I’m searching for a good while for a good deploying method, when the clients are not in a domain.

okay, i have to wake up this thread again.

We still have this issue that some Libraries get stuck and i have to resync again. It happens to everyone who is in this library, regardles of the client version. I changed AutoLock to 4 hours. And all clients who have access to this are on version 5.1.3 or higher.

i rarely have any unlocks in seafile.log

Is there anything i can do?

Can you check the database whether there is any entry in the FileLock table for this library?

It would be really nice if Seafile could get the client included in ninite.

https://ninite.com

1 Like

… a bit later …

We still have this error. I checked the File Locks Table and yes, there is an entry for this particular library.
But just on one file. How comes that it can break the complete sync prozess of Seafile.

If i wait long enough, and the lock drops, the client starts to sync again. But until the lock drops, seafile stops working.

Every client in this Library is now on 6.0.7

@Andre Does the problematic client tries to update the locked file?

how can i tell?

The user didn’t even open the folder. There is no entry in die seafile.log. So i would say no. Except it had something to do with our Antivirus. The file, the user locked, was new (.docx).

Now the funny Part. Since today (yesterday we had the file lock from the user) the user can’t sync the Library … she gets the same error.

A litle timeline how i observed this:
1: User1: makes changes to a library (massive changes)

2: User2: locks a file (why is unknown, possible antivirus, never went into the library)

`FileLocks` VALUES ('c63d48d2-5837-41c9-8e34-9fe0cd33c16e','Aktuelle Listen/filename.docx','user@email.tld',1505311291,0);

3: User1: gets thrown out of the library (no permission)

(example screenshot, looks allways the same)

4: Server: drops the lock

[09/13/2017 06:51:56 PM] filelock-mgr.c(947): 1 expired file locks are unlocked.

5: User1: [next day] is locked out of the library (there is NO Filelock anymore in the database for this library)

[09/14/17 13:45:39] sync-mgr.c(702): Repo 'A 2 LIB' sync state transition from 'synchronized' to 'uploading'.
[09/14/17 13:45:39] http-tx-mgr.c(3423): Upload with HTTP sync protocol version 1.
[09/14/17 13:45:39] http-tx-mgr.c(1132): Transfer repo 'c63d48d2': ('normal', 'init') --> ('normal', 'check')
[09/14/17 13:45:39] http-tx-mgr.c(1132): Transfer repo 'c63d48d2': ('normal', 'check') --> ('normal', 'commit')
[09/14/17 13:45:39] http-tx-mgr.c(1132): Transfer repo 'c63d48d2': ('normal', 'commit') --> ('normal', 'fs')
[09/14/17 13:45:40] http-tx-mgr.c(1132): Transfer repo 'c63d48d2': ('normal', 'fs') --> ('normal', 'data')
[09/14/17 13:45:40] http-tx-mgr.c(1132): Transfer repo 'c63d48d2': ('normal', 'data') --> ('normal', 'update-branch')
[09/14/17 13:45:40] http-tx-mgr.c(3330): Bad response code for PUT https://sub.domain.tld/seafhttp/repo/c63d48d2-5837-41c9-8e34-9fe0cd33c16e/commit/HEAD/?head=751fbc292a6f4764db1cbf33b0fef99a2d5040dc: 403.
[09/14/17 13:45:40] http-tx-mgr.c(3546): Failed to update branch of repo c63d48d2.
[09/14/17 13:45:40] http-tx-mgr.c(1132): Transfer repo 'c63d48d2': ('normal', 'update-branch') --> ('error', 'finished')
[09/14/17 13:45:40] sync-mgr.c(764): Repo 'A 2 LIB' sync state transition from uploading to 'error': 'You do not have permission to access this library'.

[CUT]

Some extra observations: almost ALL .ELM files got “changed” by (almost) all users who are in sync with this library. BUT the history of the file itself says its never changed at all. I think this is something in common with the Seafile 6.1.0 vs. Antivirus problem. https://forum.seafile.com/t/seafile-client-6-1-0-eml-files-and-antivirus/3772/10

The Library history tells me this file got changed by 4 users. First the “User1” who put in in the library. Then almost at the same time 3 other users/clients (This library has only 5 users). But in the file history is nothing at all execpt the creation of the file.

  • fun part is only 2 users got kicked out, not all 5.
  • another thing… my client did nothing, he didn’t read the eml files nor is he locked out. But the machines are almost the same (Windows 7/10, Eset Endpoint Security, Seafile Client 6.0.7)

@Andre It’s currently hard to debug such kind of permission issues. So we’ve added more detailed permission errors in the next 6.1 version. It’s going to be released soon. By then you can see the detailed error in the admin panel.

Regarding the eml file issue, I think some program just constantly changes the last modification time of the eml files. But the contents are not changed.

Do you mean 6.2?

This is a pro feature issue. So it’ll be in Pro 6.1.9 I think.

Ah ok, i was asking because you already released 6.2 CE