Library gets into unrecoverable error state, after permission change (owner change) on the server

[egroeper]

This seems to be a follow-up error of #937.

I have a user, that had the error symptoms of #937 for some time. Then something happened (don't know what, couldn't reproduce it yet) and the library went into an partly unsynced state. Instead of the exclamation mark, the cloud symbol of unsynced libraries is shown, but the error message still exists:

The gui handles the library as unsynced now, so resyncing isn't possible anymore. "Download and sync" isn't working either (same target directory or a different one). Error message: "Task already in progress"

The problem occured with client version 6.0.4, but persists with 6.0.6.

Here are the logs:

[06/12/17 10:49:03] seaf-daemon.c(555): starting seafile client 6.0.4
[06/12/17 10:49:03] seaf-daemon.c(557): seafile source code version 6c6b968d1dbf35539eb103f705c8c167ffa5fbe4
[06/12/17 10:49:03] ../common/mq-mgr.c(60): [mq client] mq cilent is started
[06/12/17 10:49:03] ../common/mq-mgr.c(106): [mq mgr] publish to heartbeat mq: seafile.heartbeat
[06/12/17 10:49:05] sync-mgr.c(702): Repo 'LibraryName' sync state transition from 'synchronized' to 'uploading'.
[06/12/17 10:49:05] http-tx-mgr.c(3400): Upload with HTTP sync protocol version 1.
[06/12/17 10:49:05] http-tx-mgr.c(1109): Transfer repo 'ccd0939f': ('normal', 'init') --> ('normal', 'check')
[06/12/17 10:49:05] http-tx-mgr.c(2232): Bad response code for GET https://box.hu-berlin.de/seafhttp/repo/ccd0939f-f3c4-4f9a-bf4c-fd824752c41e/permission-check/?op=upload&client_id=ec252d57c33a920a71dcd3bbcd6bcb8d8ad19e91&client_name=TheClient: 403.
[06/12/17 10:49:05] http-tx-mgr.c(3418): Upload permission denied for repo ccd0939f on server https://box.hu-berlin.de.
[06/12/17 10:49:05] http-tx-mgr.c(1109): Transfer repo 'ccd0939f': ('normal', 'check') --> ('error', 'finished')
[06/12/17 10:49:05] sync-mgr.c(764): Repo 'LibraryName' sync state transition from uploading to 'error': 'You do not have permission to access this library'.
[06/12/17 10:49:19] sync-mgr.c(702): Repo 'LibraryName' sync state transition from 'synchronized' to 'uploading'.
[06/12/17 10:49:19] http-tx-mgr.c(3400): Upload with HTTP sync protocol version 1.
[06/12/17 10:49:19] http-tx-mgr.c(1109): Transfer repo 'ccd0939f': ('normal', 'init') --> ('normal', 'check')
[06/12/17 10:49:19] http-tx-mgr.c(2232): Bad response code for GET https://box.hu-berlin.de/seafhttp/repo/ccd0939f-f3c4-4f9a-bf4c-fd824752c41e/permission-check/?op=upload&client_id=ec252d57c33a920a71dcd3bbcd6bcb8d8ad19e91&client_name=TheClient: 403.
[06/12/17 10:49:19] http-tx-mgr.c(3418): Upload permission denied for repo ccd0939f on server https://box.hu-berlin.de.
[06/12/17 10:49:19] http-tx-mgr.c(1109): Transfer repo 'ccd0939f': ('normal', 'check') --> ('error', 'finished')
[06/12/17 10:49:19] sync-mgr.c(764): Repo 'LibraryName' sync state transition from uploading to 'error': 'You do not have permission to access this library'.
[06/12/17 10:49:38] clone-mgr.c(840): Transition clone state for ccd0939f from [init] to [check server].
[06/12/17 10:49:38] http-tx-mgr.c(1371): Bad response code for GET https://box.hu-berlin.de/seafhttp/repo/ccd0939f-f3c4-4f9a-bf4c-fd824752c41e/commit/HEAD: 403.
[06/12/17 10:49:38] clone-mgr.c(857): Transition clone state for ccd0939f from [check server] to [error]: check server.
[06/12/17 10:49:43] clone-mgr.c(840): Transition clone state for ccd0939f from [error] to [check server].
[06/12/17 10:49:43] http-tx-mgr.c(1371): Bad response code for GET https://box.hu-berlin.de/seafhttp/repo/ccd0939f-f3c4-4f9a-bf4c-fd824752c41e/commit/HEAD: 403.
[06/12/17 10:49:43] clone-mgr.c(857): Transition clone state for ccd0939f from [check server] to [error]: check server.

First everything seems to be like in #937, but the at 10:49:38 something has changed and since then we have this other error state.

[freeplant]

To quickly bypass the problem, the user can rename the local folder to a new name, wait a few seconds until the library get unsynced. Then the user can change the name back and resync the library.

[egroeper]

To be honest: I don't know since when this library is in this new error state. But the user had another library with symptoms like in #937, that could be fixed by resync. This issue is special and since the log messages for this library change at this point in time, I assume, that the symptoms seen in the gui exist since then.

@freeplant Thanks for the workaround. Will test that.

[fadialzammar]

I'm still encountering what is essentially the same bug. I tried using seaf-cli to download a library, but selected a directory the current user did not have permissions for and now get the following when trying to download it again with the correct permissions:

Starting to download ...
Library {library_id} will be downloaded to {library_destination}
Traceback (most recent call last):
  File "/usr/bin/seaf-cli", line 1038, in <module>
    main()
  File "/usr/bin/seaf-cli", line 1034, in main
    args.func(args)
  File "/usr/bin/seaf-cli", line 587, in seaf_download
    seafile_rpc.download(repo,
  File "/usr/lib/python3/dist-packages/pysearpc/client.py", line 127, in newfunc
    return fret(ret_str)
  File "/usr/lib/python3/dist-packages/pysearpc/client.py", line 25, in _fret_string
    raise SearpcError(dicts['err_msg'])
pysearpc.common.SearpcError: Task is already in progress

It does not show up under seaf-cli list, because it hasn't started syncing yet. Selecting a different directory to download to does not work. The only way I resolved this was by deleting both my client data directory and ~/.ccnet to start from a fresh install.