Error when uploading plugins [self-hosted]

This error is similar to a previous one, but affects a fresh install of seatable and a newer version.

I am running seatabl developer edition version 1.8.0 via docker and have issues installing plugins from – the admin user interface shows a simple “Error” message when I upload a plugin zip, the server returns a 500 error.

dtable_web.log gives the following python error Invalid repo id.

Log file excerpt
2021-03-27 14:44:21,872 [ERROR] django.request:135 handle_uncaught_exception Internal Server Error: /api/v2.1/admin/dtable-system-plugins/
Traceback (most recent call last):
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/core/handlers/", line 41, in inner
    response = get_response(request)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/core/handlers/", line 249, in _legacy_get_response
    response = self._get_response(request)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/core/handlers/", line 187, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/core/handlers/", line 185, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/views/decorators/", line 58, in wrapped_view
    return view_func(*args, **kwargs)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/views/generic/", line 68, in view
    return self.dispatch(request, *args, **kwargs)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/rest_framework/", line 505, in dispatch
    response = self.handle_exception(exc)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/rest_framework/", line 465, in handle_exception
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/rest_framework/", line 476, in raise_uncaught_exception
    raise exc
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/rest_framework/", line 502, in dispatch
    response = handler(request, *args, **kwargs)
  File "/opt/seatable/seatable-server-latest/dtable-web/seahub/api2/endpoints/admin/", line 238, in post
    plugin_path_id = seafile_api.get_dir_id_by_path(PLUGINS_REPO_ID, plugin_path)
  File "/opt/seatable/seatable-server-latest/seafile/lib/python3.7/site-packages/seaserv/", line 230, in get_dir_id_by_path
    return seafserv_threaded_rpc.get_dir_id_by_path(repo_id, path)
  File "/opt/seatable/seatable-server-latest/seafile/lib/python3.7/site-packages/pysearpc/", line 128, in newfunc
    return fret(ret_str)
  File "/opt/seatable/seatable-server-latest/seafile/lib/python3.7/site-packages/pysearpc/", line 26, in _fret_string
    raise SearpcError(dicts['err_msg'])
pysearpc.common.SearpcError: Invalid repo id

I noticed there is an empty variable in called PLUGINS_REPO_ID, but I do not understand what type of ID I would need to fill in there.

All other file-based operations, like uploading images into tables, or changing user pictures, work on my deployment.

Any hint what could be the issue here and if I’m even looking at the right places for error messages would be greatly appreciated!

Welcome to the SeaTable Forum!

The parameter informs SeaTable in which repository to save the uploaded plugins. In your case, SeaTable has no idea where to put the plugin.

The repo ID for the plugins is auto-generated. There’s no need for manual manipulation/modification.

If you don’t have any data in your instance, remove the /opt/seatable directory and start over again.

Thank you for pointing that out.

All I did was basically type docker-compose up to initialize the deployment, and didn’t touch any configuration file. I can try erasing the contents of the mounted volume and start again, but wonder what I could do different this time, or what logs I could monitor during the setup to catch why the repo ID was not generated?

This is what happened after I shut down seatable, deleted the contents of /opt/seatable, and ran the initialization process again (via docker-compose up):

The line PLUGINS_REPO_ID='' was added to /opt/seatable/seatable/conf/ – so the repo is is still empty, and the error pysearpc.common.SearpcError: Invalid repo id continues to appear when I try to upload plugins.

Maybe I am missing something and there is an additional configuration step that would need to be taken?

Another small after deleting contents of /opt/seatable: my previous tables are displayed, but are not accessible anymore (error message is 'Library does not exist."). It has also become impossible to create new bases, trying to do so returns the message “Library 876bae96-2c98-460f-aae1-a2138b01fc9d not found.”

I believe deleting /opt/seatable is not enough, but the database has to be reset completely as well?

Summary: a value for PLUGINS_REPO_ID is not generated for new installs of seatable 1.8.0 developer edition. When the service is run for the first time, the line PLUGINS_REPO_ID='' is appended to seatable-data/seatable/conf/

After deleting /opt/seatable and dropping the 3 databases created by seatable (seafile_db, ccnet_db, and dtable_db), launchin seatable still results in an empty repo ID and all previously described issues remain.

Additionally, it is impossible to “clean” the database as described in the manual, because the helper script also relies on PLUGINS_REPO_ID being set.

If desired, I can file a bug in the main seatable GitHub repo, or create a new bug report in this forum.

Hi again,
I just did the following on a vserver on which I had installed SeaTable EE just a few days ago:

  • I removed the directory /opt/seatable including subfolders with rm -R /opt/seatable to remove SeaTable entirely from the server
  • I recreated the directory cd /opt && mkdir seatable
  • I pulled the most recent SeaTable DE image docker pull seatable/seatable:latest
  • I downloaded the docker-compose.yml with wget into /opt/seatable
  • I modified the SEATABLE_SERVER_HOSTNAME and set SEATABLE_SERVER_LETSENCRYPT to True (left the database password unchanged because the installation is for testing purposes anyway)
  • I ran docker-compose up , got myself a glass of water, and aborted the process
  • I ran docker-compose up -d
  • I ran these two commands:
# Start SeaTable service.
docker exec -d seatable /shared/seatable/scripts/ start
# Create an admin account.
docker exec -it seatable /shared/seatable/scripts/ superuser 

I could log into my brand new SeaTable DE instance with the superuser account I just created, I could upload plugins and the repo_id for plugins was set in the

Please follow the recipe above and you’ll succeed in installing SeaTable DE.

The script, you refer to, is not meant to purge the database. It’s simply meant “to clear records older than 30 days in dtable_db database” - as explained under the link in your post. So you expect a behavior the script was not designed to bring about.

Thanks for the exact installation steps, which I reproduced on a different system, and on the system I originally had issues with.

The system that originally had issues still didn’t generate the repo id, the other system did. It looks like the problem is that I didn’t fetch a glass of water, as you recommend :slightly_smiling_face:: The failing system uses much slower storage, and I probably ran the initialization commands too quickly after docker-compose up -d. When I tried again and waited some time, the initialization of the variable worked. :+1:

Reading the source I figured out that deleting the problematic line PLUGINS_REPO_ID='' in, and the running the, will generate the desired repo id and insert it into the settings file. ( only checks if the string “PLUGINS_REPO_ID” is present in the settings file, but not if it is set to a meaningful value, that’s why it has to be deleted.)

AFAIK the depends_on declarations in docker compose ensures that containers are started in a certain order, but there is no guarantee that the service inside a previously started container is ready and accepting connections when the next container is started. This can lead to cases where errors are hard to reproduce across systems with varying performance. Some docker projects use the workaround to make sure that for instance database and redis are actually done initializing before running the main application. Maybe that’s an approach seatable could use too.

I’m sorry for causing this confusion with my slow RAID :sweat_smile:

1 Like