ep_aa_file_menu_toolbar crashes the app

[kimllee]

Hello,

Looks like another plugin (ep_aa_file_menu_toolbar) crashes the app (v2.7.3)
Thanks

[2026-05-10T19:46:10.216] [ERROR] settings - Failed to load hook function "/opt/etherpad-lite/src/plugin_packages/ep_aa_file_menu_toolbar/eejs:eejsBlock_body" for plugin "ep_file_menu_toolbar" part "aa_file_menu_toolbar" hook set "hooks" hook "eejsBlock_body": Error: Cannot find module '/opt/etherpad-lite/src/plugin_packages/ep_aa_file_menu_toolbar/eejs'
Require stack:
- /opt/etherpad-lite/src/static/js/pluginfw/shared.ts
- /opt/etherpad-lite/src/static/js/pluginfw/plugins.ts
- /opt/etherpad-lite/src/static/js/pluginfw/installer.ts
- /opt/etherpad-lite/src/node/server.ts
    at node:internal/modules/cjs/loader:1383:15
    at nextResolveSimple (/opt/etherpad-lite/node_modules/.pnpm/tsx@4.21.0/node_modules/tsx/dist/register-D46fvsV_.cjs:4:1004)
    at /opt/etherpad-lite/node_modules/.pnpm/tsx@4.21.0/node_modules/tsx/dist/register-D46fvsV_.cjs:3:2630
    at /opt/etherpad-lite/node_modules/.pnpm/tsx@4.21.0/node_modules/tsx/dist/register-D46fvsV_.cjs:3:1542
    at resolveTsPaths (/opt/etherpad-lite/node_modules/.pnpm/tsx@4.21.0/node_modules/tsx/dist/register-D46fvsV_.cjs:4:760)
    at Function._resolveFilename (/opt/etherpad-lite/node_modules/.pnpm/tsx@4.21.0/node_modules/tsx/dist/register-D46fvsV_.cjs:4:1102)
    at defaultResolveImpl (node:internal/modules/cjs/loader:1025:19)
    at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1030:22)
    at Function._load (node:internal/modules/cjs/loader:1192:37)
    at TracingChannel.traceSync (node:diagnostics_channel:328:14)

[JohnMcLear]

Can you provide steps to replicate please? Installed w/ CLI or admin page? Any other plugins?

I think this is fixed in 0.2.52

[kimllee]

I installed it through the admin page.
I have removed the container and the volumes linked and reapplied a "docker compose up".

With the latest docker image version in the logs :

Is it normal please ?

I'm using a rpi5 with Debian 13

[JohnMcLear]

Thanks for the screenshot — that helps a lot.

Two separate things going on here:

1. The original crash (your first message)

The stack trace is misleading: the crashing plugin is ep_file_menu_toolbar (note: not ep_aa_file_menu_toolbar), versions 0.2.45–0.2.47. Those releases shipped a package.json named ep_file_menu_toolbar but an ep.json whose hooks point at ep_aa_file_menu_toolbar/eejs. When Etherpad tries to resolve the hook path it looks for a sibling package that doesn't exist → the Cannot find module …/ep_aa_file_menu_toolbar/eejs error you saw.

That packaging bug was fixed upstream in ep_file_menu_toolbar@0.2.48 (latest is 0.2.52). If you actually wanted the other plugin (the ep_aa_… fork), ep_aa_file_menu_toolbar@0.2.20 installs cleanly here. Either way, updating away from 0.2.45–0.2.47 will fix the original error.

2. The new screenshot

That's pnpm 11 mid-install, prompting interactively:

? The modules directories will be removed and reinstalled from scratch. Proceed? (Y/n) › true

pnpm only emits that when the on-disk node_modules state is incompatible with the current lockfile/pnpm version. The › true means something answered yes — pnpm then wipes node_modules and reinstalls. If that happens while Etherpad is already running, the live process loses its deps and the container dies. That's almost certainly the "crash" you're seeing on the second go-around, not the original hook error.

The smaller yellow banner ("11.0.6 → 11.0.9, run corepack use pnpm@11.0.9") suggests there may also be a pnpm-version drift between what built your image's node_modules and what's running in the container.

A few questions so I can dig deeper:

1. What does your docker-compose.yml look like? Specifically:
   • any volumes: mounting onto /opt/etherpad-lite or /opt/etherpad-lite/node_modules?
   • any custom entrypoint: or command:?
2. Which exact image are you on — output of docker inspect --format '{{.Image}}' <container> plus docker image inspect <image> digest? "latest" varies.
3. On a Pi 5 with Debian 13, are you on arm64? Just want to rule out an arch-mismatched image.

[JohnMcLear]

Closing this as it appears to be a plugin issue. Op please keep responding and if it is an issue we can file it in the right place and get it resolved. I have a feeling it's a stale issue tho!

[kimllee]

Okay, thank you for the plugin answer.
My docker-compose file is quite simple and adapted from https://github.com/ether/etherpad/blob/develop/docker-compose.yml

services:
  etherpad:
    user: "0:0"
    image: etherpad/etherpad:latest
    container_name: etherpad
    networks:
      - traefik
    tty: true
    stdin_open: true
    volumes:
      - plugins:/opt/etherpad-lite/src/plugin_packages
      - var:/opt/etherpad-lite/var
    environment:
      NODE_ENV: production
      ADMIN_PASSWORD: ${DOCKER_COMPOSE_APP_ADMIN_PASSWORD:-admin}
      DB_TYPE: "sqlite"
      # For now, the env var DEFAULT_PAD_TEXT cannot be unset or empty; it seems to be mandatory in the latest version of etherpad
      DEFAULT_PAD_TEXT: ${DOCKER_COMPOSE_APP_DEFAULT_PAD_TEXT:- }
      DISABLE_IP_LOGGING: ${DOCKER_COMPOSE_APP_DISABLE_IP_LOGGING:-false}
      SOFFICE: ${DOCKER_COMPOSE_APP_SOFFICE:-null}
      TRUST_PROXY: ${DOCKER_COMPOSE_APP_TRUST_PROXY:-true}
      COOKIE_SAME_SITE: None     # required when embedded in a cross-origin iframe
      COOKIE_SECURE: true        # required when SameSite=None
      SOCKETIO_MAX_HTTP_BUFFER_SIZE: 10000
      SOCKET_IO_ALLOW_UPGRADE: true
      ETHERPAD_PROTOCOL: https
      ETHERPAD_HOST: ${DOMAIN}
    restart: unless-stopped
    ports:
      - "${DOCKER_COMPOSE_APP_PORT_PUBLISHED:-9001}:${DOCKER_COMPOSE_APP_PORT_TARGET:-9001}"
    labels:
      - "traefik.enable=true"
      -  ............
volumes:
  plugins:
  var:
networks:
  traefik:
    external: true
      

I cleaned the old docker image before posting :)
This is the same image used in the container and this stored in the rpi

[JohnMcLear]

Thanks — that helps narrow it.

A few things stand out from the compose + image info:

• Image: etherpad/etherpad:latest digest sha256:e277b0f0…2e32b0b0, arm64 — that's the official Docker Hub image (same build as ghcr.io/ether/etherpad), so this isn't a fork or stale third-party image.
• No source/node_modules bind mount. Your only volumes are plugins:/opt/etherpad-lite/src/plugin_packages and var:/opt/etherpad-lite/var — both named volumes for state, not source overrides. Good — that rules out the most common cause of pnpm wanting to reinstall on startup.
• user: "0:0" — running as root inside the container. Worth flagging but not the cause here.
• tty: true + stdin_open: true — that's why the pnpm prompt is showing up at all instead of being non-interactive. Without those, pnpm would either skip the prompt or fail immediately.

The image's CMD is just pnpm run prod, which chains to node --require tsx/cjs node/server.ts. It does not run pnpm install on startup. So either:

1. Something inside the container is invoking pnpm install itself (e.g., a plugin's postinstall, or the admin UI's update flow), or
2. pnpm run prod itself is detecting an inconsistent workspace state on startup and offering to reinstall from scratch — most likely if the plugins volume contains plugin packages whose own package.json deps don't match the image's prebuilt node_modules.

To pin it down, two requests:

a. Full container logs from a clean start — from docker compose up all the way to crash:

docker compose down
docker volume rm <project>_plugins <project>_var   # if you can; this nukes plugins+state
docker compose up | tee etherpad-startup.log

…and attach etherpad-startup.log. The first ~50 lines before that pnpm prompt are the interesting bit.

b. Have you ever clicked "Update Etherpad" in the admin UI? Etherpad's built-in updater calls pnpm install --frozen-lockfile against the lock backed up in var/update-backup/. If a previous update was interrupted and var/update-backup/pnpm-lock.yaml is now stale, that could explain why a follow-up restart wants to reinstall. Worth running:

docker compose exec etherpad ls -la /opt/etherpad-lite/var/update-backup/
docker compose exec etherpad cat /opt/etherpad-lite/var/update-state.json 2>/dev/null || true

In the meantime, the original crash (your first message) is independent of the pnpm-reinstall question and can be fixed right now: update the plugin away from ep_file_menu_toolbar@0.2.45–0.2.47 (latest 0.2.52 has the ep.json bug fixed), or use ep_aa_file_menu_toolbar@0.2.20 if that's the one you actually wanted.

[kimllee]

Thanks, I know about root user and I also know that the app could work without it as my opencloud + colllabora apps do. I'll change it when I will have no more issues with Etherpad :)

With these settings tty: true + stdin_open: true commented out the app failed to launch

Scope: all 3 workspace projects
[ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY] Aborted removal of modules directory due to no TTY

If you are running pnpm in CI, set the CI environment variable to "true", or set "confirmModulesPurge" to "false".
[ERROR] Command failed with exit code 1: /usr/local/bin/node /root/.cache/node/corepack/v1/pnpm/11.0.6/bin/pnpm.mjs install --production

pnpm: Command failed with exit code 1: /usr/local/bin/node /root/.cache/node/corepack/v1/pnpm/11.0.6/bin/pnpm.mjs install --production
    at getFinalError (file:///root/.cache/node/corepack/v1/pnpm/11.0.6/dist/pnpm.mjs:28540:14)
    at makeError (file:///root/.cache/node/corepack/v1/pnpm/11.0.6/dist/pnpm.mjs:30847:21)
    at getSyncResult (file:///root/.cache/node/corepack/v1/pnpm/11.0.6/dist/pnpm.mjs:32691:10)
    at spawnSubprocessSync (file:///root/.cache/node/corepack/v1/pnpm/11.0.6/dist/pnpm.mjs:32651:14)
    at execaCoreSync (file:///root/.cache/node/corepack/v1/pnpm/11.0.6/dist/pnpm.mjs:32581:23)
    at callBoundExeca (file:///root/.cache/node/corepack/v1/pnpm/11.0.6/dist/pnpm.mjs:35109:23)
    at boundExeca (file:///root/.cache/node/corepack/v1/pnpm/11.0.6/dist/pnpm.mjs:35086:49)
    at sync (file:///root/.cache/node/corepack/v1/pnpm/11.0.6/dist/pnpm.mjs:35245:10)
    at runPnpmCli (file:///root/.cache/node/corepack/v1/pnpm/11.0.6/dist/pnpm.mjs:208411:5)
    at runDepsStatusCheck (file:///root/.cache/node/corepack/v1/pnpm/11.0.6/dist/pnpm.mjs:210115:7)
Scope: all 3 workspace projects
[ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY] Aborted removal of modules directory due to no TTY

Logs from clean install :
etherpad-startup.log

➜  sudo docker compose -f etherpad-compose.yaml up  | tee etherpad-startup.log
 Volume etherpad_plugins Creating 
 Volume etherpad_plugins Created 
 Volume etherpad_var Creating 
 Volume etherpad_var Created 
 Container etherpad Creating 
 Container etherpad Created 
Attaching to etherpad
 Container etherpad Starting 
 Container etherpad Started 
etherpad  | Scope: all 3 workspace projects
etherpad  | ? The modules directories will be removed and reinstalled from scratch. Proceed? (Y/n) ‣ true
etherpad  |    ╭──────────────────────────────────────────────╮
etherpad  |    │                                              │
etherpad  |    │      Update available! 11.0.6 → 11.0.9.      │
etherpad  |    │     Changelog: https://pnpm.io/v/11.0.9      │
etherpad  |    │   To update, run: corepack use pnpm@11.0.9   │
etherpad  |    │                                              │
etherpad  |    ╰──────────────────────────────────────────────╯
etherpad  | 

I don't have more logs.

[JohnMcLear]

That stack trace nails it. Diagnosis:

Root cause

runDepsStatusCheck is pnpm 11's automatic pre-run hook: every pnpm run <script> first compares node_modules to pnpm-lock.yaml, and if it thinks they're out of sync it spawns pnpm install --production automatically. With a TTY it prompts ("modules directories will be removed and reinstalled… Proceed?"); without a TTY it bails with ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY — exactly what you're seeing.

Our CMD ["pnpm", "run", "prod"] is what triggers it. The image's node_modules is actually fine — pnpm's heuristic just trips on first start, almost certainly because the named volume on src/plugin_packages perturbs the workspace fingerprint right when the container comes up.

This affects every Docker user on this image once the named volume layout is applied. I owe you a fixed image.

Immediate workaround (no rebuild needed)

Either of these in your compose file will unblock you right now:

Option A — set CI=true so pnpm auto-confirms instead of prompting/aborting:

environment:
  CI: "true"

Option B — bypass pnpm at runtime entirely (skips the deps check):

command: ["sh", "-c", "cd src && node --require tsx/cjs node/server.ts"]

I'd suggest Option B — it's not just a workaround, it's basically what the proper fix will be.

The proper fix

I'll open a PR to make the image's CMD bypass pnpm run so the deps-check never fires. Will link the PR here when it's up, and once it ships the next etherpad/etherpad:latest will Just Work.

And the original crash

Unrelated to all this — your first message's Cannot find module …ep_aa_file_menu_toolbar/eejs is the ep_file_menu_toolbar@0.2.45–0.2.47 packaging bug. Update to 0.2.48+ (latest 0.2.52) and that one is gone.

[JohnMcLear]

PR up: #7727 — once CI is green and it lands, the next etherpad/etherpad:latest image republish will fix this for you with no compose changes needed. The workaround above unblocks you immediately in the meantime.

[JohnMcLear]

Fix shipped 🚀

#7727 merged at `c7100e0ba` and the Docker workflow republished both `etherpad/etherpad:latest` (Docker Hub) and `ghcr.io/ether/etherpad:latest` (GHCR) a few minutes ago.

When you're ready, on the Pi:

```
docker compose pull etherpad
docker compose down
docker compose up -d
```

You shouldn't need any of the workarounds anymore — the new image's `CMD` invokes `node` directly, so pnpm 11's `runDepsStatusCheck` never runs at boot. Your existing `docker-compose.yml` (with the `plugins:` and `var:` named volumes) should boot cleanly even without `tty: true` / `stdin_open: true`.

To verify you got the new image:

```
docker image inspect etherpad/etherpad:latest --format '{{.Config.Cmd}}'
```

Should now print: `[sh -c cd src && exec node --require tsx/cjs node/server.ts]` instead of `[pnpm run prod]`.

And — independently of all this — make sure to bump `ep_file_menu_toolbar` past 0.2.47 (0.2.52 is current) to clear the original `Cannot find module …ep_aa_file_menu_toolbar/eejs` error from your first report.

Let us know how it goes!