Issues Installing/Uploading Plugins on Self-Hosted SeaTable Enterprise 5.2.7

[carloshedzm]

Hello SeaTable Community,

Setup:

I have a self-hosted SeaTable Enterprise Edition v5.2.7 instance (Docker Compose on a Google Cloud VM, Debian 12). Most functionalities of my instance are operating correctly.

Describe the Problem/Error/Question:

Failure when Installing Plugins from the Marketplace:
I can see the “Plugin Marketplace” and the full catalog of official plugins (see image_b7e57b.png). But, when I click “Install” for any plugin, the operation fails, and the UI displays a generic “Error” popup.

Failure when Uploading Plugins Manually:
If I try to use the “Upload plugin” option from System Admin → Plugins, this operation also results in an “Error” (see subir plugins.jpg).

My main questions are:

Is there any additional configuration or specific requirements needed to correctly enable plugin installation and uploading on a self-hosted SeaTable Enterprise 5.2.7 instance?
Is this a known issue or a common problem for new installations of this version?

Error Messages:

I am ready to provide any logs or configuration details you might indicate are necessary to help resolve this.

Thank you for any guidance.

[Julia]

Maybe you can open the browser console, and network panel to view specific error messages or whether the server has relevant error logs.

[carloshedzm]

@Julia

cíficos o si el servidor tiene registros de errores releva

So, in principle, I should be able to install plugins?

Are there no additional settings to activate them?

Thank you very much for your response.

[cdb]

There are no requirements to install SeaTable Plugins. SeaTable just downloads a list of available plugins from here https://market.seatable.io/api/plugins/.

If you want to install a plugin, it just downloads a zip file and that’s it.

[abaer]

Hi, that error (even though it’s very generic) looks familiar. Checking the obvious:

• Is your Seatable Server actually allowed to access the internet
  • Can you curl / wget anything in the WWW from inside the seatable-server container?
• Even if that is the case, does your server need to use a proxy for outside connections?

[carloshedzm]

Hi, thanks for responding.

My server is indeed online:

That’s my configuration:

• Hardware or environment you use: Google Cloud VM (2 vCPU, 4GB RAM)
• OS: Debian GNU/Linux 12 (bookworm) amd64 built on 20250415
• SeaTable Edition: Enterprise

I’ve been working with the Seatable installation, and I’ve even been testing successful database imports from Airtable.

I just wanted to make sure I don’t need any special configuration to install plugins.

In any case, I appreciate your attention to this message.

[carloshedzm]

Hi,

I just wanted to know if I should enable any additional variables.

I tried accessing this answer where they apparently describe errors when trying to install plugins, but it was no longer available.

Blockquote Failed to load resource (plugins, avatars, CSS) - #4 by rdb

I was looking for a similar case.

I just wanted to make sure I didn’t need any special configuration to install plugins.

I’ll continue testing on my instance.

Thank you very much for your kind response.

[carloshedzm]

Thanks again for your previous response.

Since you mentioned that no additional configuration is needed,

and the Seatable installation is practically new, I see some errors recurring in the logs.

I’ve confirmed that SEATABLE_PLUGINS_REPO_ID is not set in my .env file. However, my dtable_web.log consistently shows the following traceback and pysearpc.common.SearpcError: Invalid repo id when the system attempts to access /api/v2.1/admin/dtable-system-plugins/:

Traceback (most recent call last):
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
  File "/opt/seatable/seatable-server-latest/dtable-web/thirdpart/django/core/handlers/base.py", line 197, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/opt/seatable/seatable-server-latest/dtable-web/seahub/api2/endpoints/admin/sys_plugins.py", line 266, 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/site-packages/seaserv/api.py", line 256, 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/site-packages/pysearpc/client.py", line 127, in newfunc
    return fret(ret_str)
  File "/opt/seatable/seatable-server-latest/seafile/lib/python3/site-packages/pysearpc/client.py", line 25, in _fret_string
    raise SearpcError(dicts['err_msg'])
pysearpc.common.SearpcError: Invalid repo id

When I inspect /shared/seatable/conf/dtable_web_settings.py inside the seatable-server container, what should the value of PLUGINS_REPO_ID be for SeaTable Enterprise 5.2.7 if I intend to use the official marketplace (market.seatable.io) and not a self-hosted Seafile library for plugins? If it’s currently PLUGINS_REPO_ID = '' by default, this seems to be causing the “Invalid repo id” error.

Could this also be the reason why manual plugin uploads (to /api/v2.1/admin/plugins/upload/) are failing with a 500 error, even if a different traceback isn’t explicitly logged for that specific URL?

What is the recommended configuration for PLUGINS_REPO_ID in dtable_web_settings.py for this version to correctly use the official plugin marketplace and allow manual uploads?

Thank you in advance for your attention to this message.

[cdb]

Remove this complete line with PLUGINS_REPO_ID='' from your dtable_web_settings.py and restart all containers. Don’t just comment the line, remove it.

[carloshedzm]

Thanks for the ongoing discussion. I have an important update on the PLUGINS_REPO_ID issue.

I removed the PLUGINS_REPO_ID = '' line and restarted all containers.

Result:
The line PLUGINS_REPO_ID = '' reappeared in dtable_web_settings.py after the restart.

This confirms that the seatable-server container startup scripts are regenerating this setting with an empty string, likely because SEATABLE_PLUGINS_REPO_ID is not defined in my .env file.

Consequently, the error pysearpc.common.SearpcError: Invalid repo id for POST /api/v2.1/admin/dtable-system-plugins/ (when trying to install from the store) persists in dtable_web.log.

Manually uploading the plugin (to POST /api/v2.1/admin/plugins/upload/) continues to fail with a 500 error in the browser,
with no specific trace logged in dtable_web.log for this specific upload URL (the only Python error logged is “Invalid repository ID” for /dtable-system-plugins/).

The question is:

What should happen after restarting all services if SEATABLE_PLUGINS_REPO_ID is not defined in the .env file?

Should the line PLUGINS_REPO_ID = '...' not appear in dtable_web_settings.py?
Or should it be set to a specific, valid default value to use the official market.seatable.io file (and not an empty string)?

Thanks again for your previous response and follow-up on this case.

[cdb]

This is from the script that is executed on each start. SeaTable checks, if PLUGINS_REPO_ID exists in dtable_web_settings.py. If not, it generates a seafile library and saves the new repo id to the configuration file.

This plugin repo is used to store the plugin files and -configuration. Therefore, it is mandatory for the installation of SeaTable Plugins and explains your problems.

I installed around 100+ SeaTable Server Instances and I never had this situation before, therefore I can’t give any advice.

What I would check is your configuration of the seafile component of your SeaTable server. It seems, that it is not working correctly, and the repo can not be generated.

[carloshedzm]

Your comments and feedback

showed me the path, where to go for research.

Solution: The primary issue appeared to be the automatic generation of PLUGINS_REPO_ID failing during the seatable-server container startup. This was likely because the internal Seafile RPC services were not fully ready and their RPC sockets were not available at that early stage of the boot process.

The successful workaround involved:

1. Manually Generating a Valid PLUGINS_REPO_ID:

• Entered the running seatable-server container (sudo docker compose exec seatable-server bash).
• Executed the Python command used by the seatable.sh script, after ensuring internal services had stabilized: python3 -c "from seaserv import seafile_api; repo_id = seafile_api.create_repo('plugins repo', 'plugins repo', 'dtable@seafile'); print(repo_id)"
• This successfully generated a repository ID (e.g., d7e32a76-bee0-442a-9216-db445357b76b).

2. Manually Inserting the ID into the Persistent Configuration:

• Stopped the seatable-server container.
• Edited the dtable_web_settings.py file on the host’s volume (/opt/seatable-server/seatable/conf/dtable_web_settings.py).
• Replaced or added the line PLUGINS_REPO_ID = 'MANUALLY_GENERATED_ID'.

3. Restarting seatable-server:

• Upon restarting the container, the startup script (init_plugins_repo in seatable.sh) detected that PLUGINS_REPO_ID was already present and populated. Consequently, it did not attempt to regenerate it, allowing the manually set value to persist.

Following these steps, the PLUGINS_REPO_ID variable was correctly set, and the plugin installation and upload functionality was restored.

Thank you for your attention to this issue.

And thank you to the other people who commented.

Best regards.