500 error after sharing Folder in Library for Group

mr.evg4 · November 11, 2025, 9:17pm

I am using Seafile 13.0.12 CE in Docker.
I have a path like:
01/02/03/04/05

These are nested directories, each containing its own files. Real name of folders is non latin

If I create a group called “Group 1”, add several users to it, and share directories with the group as follows:

Directory 01 with all nested subdirectories
Directory 02 with all nested subdirectories
Directory 03 with all nested subdirectories
Directory 04 with all nested subdirectories
Directory 05

Then:

The first option works correctly.
The second option also works correctly.
The third option works correctly.

However, with the fourth option, the following problem occurs: when trying to open a file for editing via OnlyOffice, a 500 error appears:

Page unavailable
Sorry, but the requested page is unavailable due to a server hiccup.
Our engineers have been notified, so check back later.

Additionally, a second issue appears: if users add their own files or directories to the shared directory 04, other users cannot see these files. This problem does not occur with options 1-3 or 5.

In the log /opt/seafile-data/seafile/logs/seahub.log:

[2025-11-11 22:08:49] [ERROR] django.request:253 log_response Internal Server Error: /lib/7fab788d-823f**************32c92a77/file/test.docx
Traceback (most recent call last):
File “/opt/seafile/seafile-server-13.0.12/seahub/thirdpart/django/core/handlers/exception.py”, line 55, in inner
response = get_response(request)
^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/thirdpart/django/core/handlers/base.py”, line 197, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/seahub/auth/decorators.py”, line 26, in _wrapped_view
return view_func(request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/seahub/base/decorators.py”, line 59, in _decorated
return func(request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/seahub/views/file.py”, line 839, in view_lib_file
onlyoffice_dict = get_onlyoffice_dict(request, username, repo_id, path,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/seahub/onlyoffice/utils.py”, line 110, in get_onlyoffice_dict
dl_token = seafile_api.get_fileserver_access_token(repo_id,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seafile/lib/python3/site-packages/seaserv/api.py”, line 36, in get_fileserver_access_token
return seafserv_threaded_rpc.web_get_access_token(repo_id, obj_id, op, username,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seafile/lib/python3/site-packages/pysearpc/client.py”, line 127, in newfunc
return fret(ret_str)
^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seafile/lib/python3/site-packages/pysearpc/client.py”, line 25, in _fret_string
raise SearpcError(dicts[‘err_msg’])
pysearpc.common.SearpcError: Missing args

daniel.pan · November 12, 2025, 7:31am

Thanks for reporting the issue. We will look into the problem soon.

r350178982 · November 12, 2025, 10:26am

Hi， I followed the steps you described exactly, and everything worked smoothly—no issues were reproduced. After checking the source code, the root cause might be that files in the shared folder lack a valid file_path.

Could you please verify the “Share admin” settings of the library to ensure you have access to all folder shares?

Additionally, adding some debug code would help confirm that the parameters hold correct values, like the example shown in the screenshot below:

mr.evg4 · November 12, 2025, 5:14pm

I’d like to provide some additional details from the user’s perspective.

The error when opening files occurs only in folder “04_xxxxx”.
There are no errors when opening files in “03_xxxxx” or “05_xxxxx”.

Please note that the folder is shared with the group “Group xxxxxx”, of which I am a member.

In “Share Admin”:

After adding the debug line:

logger.info(f"onlyoffice_info: file_id:{file_id}, repo_id: {repo_id}, username: {username}")

==> /opt/seafile-data/seafile/logs/onlyoffice.log <==
[2025-11-12 19:42:17] [INFO] onlyoffice:95 get_onlyoffice_dict 5d*****c2@auth.local open file /test.docx in repo 7fa*******a77 with can_edit True
[2025-11-12 19:42:17] [INFO] onlyoffice:111 get_onlyoffice_dict onlyoffice_info: file_id:None, repo_id: 7fab******a77, username: 5d22ff******f82c2@auth.local

In System Admin → Libraries, the library that causes the problem does not appear.
In the “Libraries” tab, I can see only the root folders, not the subfolders (perhaps that’s expected).

However, when I go to System Admin → Groups → Libraries, I can see the folders shared with the group — those are the same folders that appear on the user’s main page.

I also found another issue for the user who is both the owner of the group and the owner of the library:
In System Admin → Users → username → Shared Links, the page loads, but in the browser’s debug console I see a 500 Internal Server Error for one of the requests.

==> /opt/seafile-data/seafile/logs/seahub.access.log <==
[12/Nov/2025:20:04:33 +0300] “GET /api/v2.1/admin/users/e207382af310fc2f%40auth.local/share-links/ HTTP/1.1" 500 285 "https:///sys/users/e2**********10fc2f%2540auth.local/shared-links” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:144.0) Gecko/20100101 Firefox/144.0” 0.091

==> /opt/seafile-data/seafile/logs/seahub.log <==
[2025-11-12 20:04:33] [ERROR] django.request:253 log_response Internal Server Error: /api/v2.1/admin/users/e207382a91**************fc2f@auth.local/share-links/
Traceback (most recent call last):
File “/opt/seafile/seafile-server-13.0.12/seahub/thirdpart/django/core/handlers/exception.py”, line 55, in inner
response = get_response(request)
^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/thirdpart/django/core/handlers/base.py”, line 197, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/thirdpart/django/views/decorators/csrf.py”, line 65, in _view_wrapper
return view_func(request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/thirdpart/django/views/generic/base.py”, line 105, in view
return self.dispatch(request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/thirdpart/rest_framework/views.py”, line 515, in dispatch
response = self.handle_exception(exc)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/thirdpart/rest_framework/views.py”, line 475, in handle_exception
self.raise_uncaught_exception(exc)
File “/opt/seafile/seafile-server-13.0.12/seahub/thirdpart/rest_framework/views.py”, line 486, in raise_uncaught_exception
raise exc
File “/opt/seafile/seafile-server-13.0.12/seahub/thirdpart/rest_framework/views.py”, line 512, in dispatch
response = handler(request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/seahub/api2/endpoints/admin/users.py”, line 1644, in get
link_info = get_user_share_link_info(fs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seahub/seahub/api2/endpoints/admin/users.py”, line 295, in get_user_share_link_info
data[‘size’] = seafile_api.get_file_size(repo.store_id,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seafile/lib/python3/site-packages/seaserv/api.py”, line 202, in get_file_size
return seafserv_threaded_rpc.get_file_size(store_id, version, file_id)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seafile/lib/python3/site-packages/pysearpc/client.py”, line 127, in newfunc
return fret(ret_str)
^^^^^^^^^^^^^
File “/opt/seafile/seafile-server-13.0.12/seafile/lib/python3/site-packages/pysearpc/client.py”, line 11, in _fret_int
raise SearpcError(dicts[‘err_msg’])
pysearpc.common.SearpcError: Invalid file id

mr.evg4 · November 12, 2025, 5:23pm

I also tried running the following command for the problematic library:

./seaf-fsck.sh -r 7fab************a77 --repair

Starting seaf-fsck, please wait …

[2025-11-12 19:32:19] [INFO] fsck.c(675): Running fsck for repo 7fabxxxxxxxxxxxxx77.
[2025-11-12 19:32:19] [INFO] fsck.c(498): Checking file system integrity of repo 04_******* (7faxxxxxxxd)…
[2025-11-12 19:32:28] [INFO] fsck.c(739): Fsck finished for repo 7faxxxxxd

I also ran ./seaf-fsck.sh --repair for all libraries. The result was the same — no errors were found.

mr.evg4 · November 12, 2025, 6:29pm

I would also like to add that the issue started with Seafile version 12. After upgrading to version 13, the problem still persists.

I began using Seafile with version 11, where this issue did not occur, as these features were not being used at that time. The upgrades to versions 12 and 13 were performed strictly following the official guide:

I also tried deploying a new Seafile 13 server and migrating the data according to the backup and restore guide:

The problem also persists on the new server.

r350178982 · November 13, 2025, 2:30am

We have reproduced the issue in Sysadmin-user-share-links—this problem is caused by invalid share links that contain an invalid file. We will work on fixing this, and in the meantime, you can use the following temporary workaround:

On the other hand, we have not yet been able to reproduce the inaccessibility of test.docx in the 04_xxx folder. From the debug information you provided, this issue is caused by a None value being returned for file_id. To further troubleshoot, we need to confirm a few points:

You mentioned being unable to open test.docx from the shared folder 04_xxx—but can you open it from the shared folders of 03_xxx or 02_xxxx? The expected paths would be 03_xx/04_xx/test.docx or 02_xx/03_xx/04_xx/test.docx
Can the library administrator open test.docx from the original library (not from a shared folder)?
Are there any errors recorded in seafile.log?

Additionally, I would like to clarify the relationship between a main library (repo) and a shared folder: When a folder in a library is shared with a user or group, a record is created in the seafile.VirtualRepo database table. This record includes:

repo_id: The ID of the virtual repository (since the shared folder is displayed as a standalone repo to the user who received the share).
origin_repo: The ID of the original main library.
path: The path of the folder in the main library that you shared.

For example: If you have a main library R that contains the folder structure a/b/c, and you share folder c (which includes a file a.txt) with a group G, a virtual repository VR will be created for group G. When you open a.txt from this shared virtual repo, the URL path will be lib/VR.repo_id/file/a.txt; if you open the same a.txt directly from the main library R, the URL path will be lib/R.repo_id/file/a/b/c/a.txt.

Based on this context, here is a small piece of debug information you can add to your code to further verify the workflow:

mr.evg4 · November 16, 2025, 1:58pm

Fixing the issue with “Shared Links” helped. Thank you.

You mentioned being unable to open test.docx from the shared folder 04_xxx — but can you open it from the shared folders of 03_xxx or 02_xxxx? The expected paths would be 03_xx/04_xx/test.docx or 02_xx/03_xx/04_xx/test.docx

– No, the file does not appear in 02_xx or 03_xx.

Can the library administrator open test.docx from the original library (not from a shared folder)?

– No, the library administrator does not see the file.

Are there any errors recorded in seafile.log?

– No, there are no errors in seafile.log.

After making the changes to utils.py, the situation is as follows:
As a user and as a member of the group “Group 1”, I can open the file test.docx, but when I try to edit the file, an error appears in the logs:

==> /opt/seafile-data/seafile/logs/onlyoffice.log <==
[2025-11-16 16:30:22] [INFO] onlyoffice:131 onlyoffice_editor_callback status 2: get doc_info {‘username’: ‘5d22fxxxxxxxxxxxxxx2c2@auth.local’, ‘repo_id’: ‘2102c4dxxxxxxxxxxxxxx75a72’, ‘file_path’: ‘/02_xxxx /03_xxxxxxx /04_xxxxxx /test.docx’} from database by doc_key c172xxxxxxxxxxbd65
[2025-11-16 16:30:22] [ERROR] onlyoffice:183 onlyoffice_editor_callback update_url: http://127.0.0.1:8082/update-api/7a92c84xxxxxxxxxxxxxxx93a174ed
[2025-11-16 16:30:22] [ERROR] onlyoffice:184 onlyoffice_editor_callback repo_id: 2102c4dххххххххххххххххххх75a72, file_path: /02_xxxx /03_xxxxxxx /03_xxxxxx /test.docx, content size: 25692
[2025-11-16 16:30:22] [ERROR] onlyoffice:186 onlyoffice_editor_callback response: {‘_content’: b’{“error”: “Parent dir doesn’t exist.\n”}', ‘_content_consumed’: True, ‘_next’: None, ‘status_code’: 400, ‘headers’: {‘Access-Control-Allow-Headers’: ‘x-requested-with, content-type, content-range, content-disposition, accept, origin, authorization’, ‘Access-Control-Allow-Methods’: ‘GET, POST, PUT, PATCH, DELETE, OPTIONS’, ‘Access-Control-Allow-Origin’: ‘*’, ‘Access-Control-Max-Age’: ‘86400’, ‘Content-Length’: ‘39’, ‘Content-Type’: ‘application/json; charset=utf-8’}, ‘raw’: <urllib3.response.HTTPResponse object at 0x7b4a6f5a8c10>, ‘url’: ‘http://127.0.0.1:8082/update-api/7a92c8xxxxxxxxxxxxxxxxxxx174ed’, ‘encoding’: ‘utf-8’, ‘history’: , ‘reason’: ‘Bad Request’, ‘cookies’: <RequestsCookieJar>, ‘elapsed’: datetime.timedelta(microseconds=6152), ‘request’: <PreparedRequest [POST]>, ‘connection’: <requests.adapters.HTTPAdapter object at 0x7b4a6f3e93a0>}

Debug:

==> /opt/seafile-data/seafile/logs/onlyoffice.log <==
[2025-11-16 16:33:53] [INFO] onlyoffice:95 get_onlyoffice_dict 5d22ffaxxxxxxxxxxxxxxf82c2@auth.local open file /test.docx in repo 7fab7xxxxxxxxxxxxxxxxxxxx92a77 with can_edit True
[2025-11-16 16:33:53] [INFO] onlyoffice:111 get_onlyoffice_dict onlyoffice_info: file_id:None, repo_id: 7fab78xxxxxxxxxxxxxxxxxxxx92a77, username: 5d22fxxxxxxxxxxxxxxxxxxx2c2@auth.local
[2025-11-16 16:33:53] [INFO] onlyoffice:116 get_onlyoffice_dict onlyoffice_info2: file_id:37c72d6dxxxxxxxxxxxxxxxxxxxbe48a00, repo_id: 7fab788xxxxxxxxxxxxxxxxxxc92a77, username: 5d22fxxxxxxxxxxxxxxxxxxxf82c2@auth.local
[2025-11-16 16:33:53] [INFO] onlyoffice:146 get_onlyoffice_dict get doc_key c172cxxxxxxxxxxxxfbd65 from database by repo_id 2102c4dxxxxxxxxxxxxxxxxx9fe875a72 file_path /02_xxxx /03_xxxxxxx /04_xxxxxx /test.docx

r350178982 · November 17, 2025, 2:32am

It seems the target file can only be accessed from folder04 as a virtual repository, but fails to display in the main repository. This issue may stem from errors during the merge of changes from the subfolder (virtual repository) into the main repository—relevant merge errors might be recorded in seafile.log.

To resolve this, the library administrator can try removing the existing share and re-sharing the folder via the library’s share admin panel, following the steps below: