AppImage is not working

[nogajun]

I downloaded and ran Etherpad-Desktop-0.4.4.appimage.
However, it did not work and displayed the following message.
The console message is as follows:

$ chmod 755 Etherpad-Desktop-0.4.4.appimage 
$ ./Etherpad-Desktop-0.4.4.appimage 
08:49:38.253 (lifecycle) › embedded etherpad source resolution {
  resourcesPath: '/tmp/.mount_EtherpXunZCd/resources',
  appRoot: '/tmp/.mount_EtherpXunZCd/resources/app.asar',
  resolved: '/tmp/.mount_EtherpXunZCd/resources/etherpad'
}
failed to boot TypeError: Cannot set properties of undefined (setting 'autoDownload')
    at createUpdater (/tmp/.mount_EtherpXunZCd/resources/app.asar/out/main/index.cjs:1839:24)
    at async boot (/tmp/.mount_EtherpXunZCd/resources/app.asar/out/main/index.cjs:2371:18)

The operating environment is Debian GNU/Linux Sid (amd64).

[matoken]

I'm having the same issue on my Debian sid amd64 and Debian 13 (trixie).
I also tried the .deb package, but the result was the same.

$ lsb_release -d
Description:    Debian GNU/Linux 13 (trixie)
$ sudo apt install ./etherpad-desktop_0.4.4_amd64.deb
$ etherpad-desktop
18:29:50.088 (lifecycle) › embedded etherpad source resolution {
  resourcesPath: '/opt/Etherpad Desktop/resources',
  appRoot: '/opt/Etherpad Desktop/resources/app.asar',
  resolved: '/opt/Etherpad Desktop/resources/etherpad'
}
failed to boot TypeError: Cannot set properties of undefined (setting 'autoDownload')
    at createUpdater (/opt/Etherpad Desktop/resources/app.asar/out/main/index.cjs:1839:24)
    at async boot (/opt/Etherpad Desktop/resources/app.asar/out/main/index.cjs:2371:18)

In the same Debian sid environment, it works when I run pnpm dev from source.

[MrDaisyBates]

Hello, on Fedora 43. Same issue. AppImage isn't working.

[MrDaisyBates]

I'm not sure if someone in the know benefits from the below, but it's what Claude (Opus 5) said was the issue when I asked. I'm not savvy with programming and such at all. So. It could be complete gibberish. I just hope maybe it gives someone with skill some lead and helps lead this to a possible solution. It did mention to me that I might be missing a FUSE library on my machine, but I do run many appimages and I do believe I've got the FUSE lib it suggested installed. So. Again. Idk if this is helpful at all, but it's about all I can personally contribute.

AppImage 0.4.4: bundled Etherpad node_modules is dropped at package time, so the embedded server can never start

Investigated Etherpad-Desktop-0.4.4.AppImage against main. There are three separate failures stacked on top of each other. The second one is the real bug and it affects every target, not just the AppImage.

---

1. AppImage runtime still requires libfuse2

The bundled runtime is the classic type-2 runtime that dlopen()s libfuse.so.2:

$ strings Etherpad-Desktop-0.4.4.AppImage | grep libfuse
dlopen(): error loading libfuse.so.2
libfuse.so.2
squashfuse 0.1.100

Fedora, and most current distros, ship fuse3 only. Users see "AppImages require FUSE to run" and nothing else happens — which is probably what some of the "doesn't work" reports are.

Workaround for users: install libfuse2 (sudo dnf install fuse on Fedora), or run with --appimage-extract-and-run.

Suggested fix: build against the newer static AppImage runtime (appImage.runtimeFile, or bump appimagetool to a type2-runtime build with static squashfuse), or at minimum document the requirement in the release notes.

---

2. Root cause: electron-builder silently drops resources/etherpad/node_modules

Once you get past FUSE, choosing "Use a local server (runs on this computer)" fails. Reproduced with the exact command the app runs:

$ cd squashfs-root/resources/etherpad/src
$ env -i HOME=/tmp/x ELECTRON_RUN_AS_NODE=1 NODE_ENV=production \
    ../../../etherpad-desktop --require tsx/cjs node/server.ts --settings /tmp/s.json

Error: Cannot find module 'tsx/cjs'
Require stack:
- internal/preload

Exit code 1, so waitForReachable reports embedded etherpad exited before becoming reachable (code=1).

What's actually in the shipped bundle

resources/etherpad/                <- no node_modules at all
resources/etherpad/src/node_modules/
├── .bin/          (esbuild, mssql only)
├── @esbuild/linux-x64
├── esbuild
└── mssql          (12 MB total)

None of the 49 runtime deps declared in src/package.json — tsx, log4js, express, ueberdb2 — are present anywhere in the AppImage.

Why

Two things interact:

(a) scripts/fetch-etherpad.mjs runs pnpm install --prod --config.node-linker=hoisted with cwd = <target>/src. Because <target> is a pnpm workspace root (pnpm-workspace.yaml lists src, admin, bin, doc, ui), the hoisted linker puts everything in the workspace root node_modules, not in src/node_modules. Minimal repro:

etherpad-fake/
  pnpm-workspace.yaml   (packages: [src])
  src/package.json      (dependencies: log4js)

$ cd src && pnpm install --prod --config.node-linker=hoisted
$ ls ../node_modules   -> date-format debug ep_etherpad-lite flatted fs-extra ... log4js
$ ls ./node_modules    -> (empty)

Only packages the linker can't hoist (platform-specific binaries: esbuild, @esbuild/*, mssql) stay nested under src/ — exactly the three that survive into the AppImage. The script's own comment already knows this: "Etherpad is a pnpm workspace — node_modules/.pnpm lives at the workspace root, not under src/."

(b) app-builder-lib's file filter hardcodes an exclusion for a node_modules directory sitting at the root of the copied tree — out/util/filter.js:

// filter the root node_modules, but not a subnode_modules
if (relative === "node_modules") {
  return false;
}

With extraResources: [{ from: resources/etherpad, to: etherpad, filter: ['**/*', ...] }], relative for the hoisted tree is literally "node_modules" — so it is dropped regardless of the **/* filter. Verified directly against the project's own config with app-builder-lib 26.15.3:

false   node_modules
true    src
true    src/node_modules
true    src/node_modules/esbuild
true    src/node/server.ts
false   bin/foo.js

The directory is rejected, so the walker never descends into it. src/node_modules passes, which is why the three unhoistable packages made it in.

This is not AppImage-specific — deb, snap, dmg and NSIS all use the same extraResources block, so all of them ship a bundled Etherpad with no dependencies.

Suggested fixes

1. One-line packaging fix: change extraResources to from: resources, to: .. The tree still lands at <resourcesPath>/etherpad (no runtime path change), but the relative path becomes etherpad/node_modules, which is not the special-cased root and gets copied.
2. Or fix the install layout: run the install with --ignore-workspace (or drop the fetched pnpm-workspace.yaml / root package.json before installing) so deps land in src/node_modules. That also matches what Etherpad itself expects — installer.ts defines node_modules = path.join(findEtherpadRoot(), 'src', 'node_modules').
3. Add a build-time guard, since this failed completely silently: after electron-builder, assert that resources/etherpad/**/node_modules/tsx exists and fail the build otherwise.
4. Improve the runtime guard. findBundledEtherpadDir only probes for src/node/server.ts, which is present, so the friendly "embedded Etherpad source not bundled…" message never fires and the user gets a raw spawn failure instead. Probing for the tsx entry point too would catch this class of breakage.

---

3. Behind that: Etherpad's boot-time pnpm dependency

I restored the missing dependencies inside the extracted AppImage (pnpm install --prod --config.node-linker=hoisted in resources/etherpad/src, 424 packages) and re-ran the same spawn. It gets much further, then dies:

[ERROR] server - Error occurred while starting Etherpad
[ERROR] server - Error: Failed to spawn pnpm: spawn pnpm ENOENT
    at exports (node/utils/run_cmd.ts:124:48)
    at migratePluginsFromNodeModules (static/js/pluginfw/installer.ts:63:50)
    at checkForMigration (static/js/pluginfw/installer.ts:88:11)
    at async Object.exports.start (node/server.ts:156:5)

This is fatal, not a warning — the process exits and never listens.

checkForMigration() calls migratePluginsFromNodeModules() whenever var/installed_plugins.json is missing, and that shells out to pnpm ls --long --json --depth=0 --no-production. Two problems for a packaged app:

• pnpm is not on a normal end user's PATH. The app runs Electron-as-node; there's no Node or pnpm on the machine.
• installedPluginsPath resolves to <etherpadRoot>/var/installed_plugins.json, inside the app bundle. That path is inside the read-only squashfs mount for the AppImage (and root-owned /opt/... for the deb), so it can never be created — meaning the migration would re-run on every launch even if pnpm existed.

var/installed_plugins.json is not shipped in the bundle (the var/ directory contains only .gitignore), so this path is hit unconditionally on first launch.

With pnpm forced onto PATH it still fails, on pnpm add pnpm@11.0.6 … --ignore-workspace followed by Command exited with code 1: pnpm ls --long --json --depth=0 --no-production.

Suggested fixes: ship a pre-generated var/installed_plugins.json so checkForMigration short-circuits, and/or relocate Etherpad's writable state (var/, plugin_packages/) into the app's userData directory rather than the read-only bundle. Longer term it'd be worth making checkForMigration non-fatal upstream when no package manager is available.

---

Environment

• Etherpad-Desktop-0.4.4.AppImage, x86-64
• Bundled Etherpad v2.7.3 (resources/etherpad/.installed-version)
• Electron 43, electron-builder 26.15.3
• Confirmed against ether/etherpad-desktop@main (build/electron-builder.yml, scripts/fetch-etherpad.mjs, .github/workflows/release.yml)