Describe the bug
The devcontainer does not produce a working environment on a clean setup, and setup.sh exits 0 with ✍️ LibreSign is up! while LibreSign is left disabled and no dependencies are installed.
To reproduce
From a clean checkout of main (0f6ffdad0) with no pre-existing Docker volumes, following .devcontainer/README.md.
There are three independent failures, chained — each one only becomes visible after the previous is worked around.
1. Default PHP_VERSION is incompatible with the Nextcloud version pulled
docker-compose.yml defaults to ghcr.io/librecodecoop/nextcloud-dev-php${PHP_VERSION:-82} while VERSION_NEXTCLOUD defaults to master (currently 35.0.0 beta 1), which requires PHP 8.3:
⌛️ Starting installation ...
This version of Nextcloud requires at least PHP 8.3<br/>You are currently running 8.2.33. Please update your PHP version.
❌ Installation failed. Check the logs above for the exact reason.
Because the service is declared restart: unless-stopped, the container retries forever. From the outside this looks like a hang rather than a failure — the error only appears in docker compose logs nextcloud.
composer.json already declares "platform": {"php": "8.3"}, so the compose default appears to have fallen behind.
Workaround: PHP_VERSION=83.
2. nextcloud/ocp stubs shadow the server's own classes
With the environment able to boot, setup.sh runs composer install (line 17), which installs dev dependencies including nextcloud/ocp. The post-install-cmd hook then runs composer dump-autoload -o, registering the OCP\ namespace from the app's vendor directory into the optimized classmap:
'OCP\\DB\\ISchemaWrapper' => $vendorDir . '/nextcloud/ocp/OCP/DB/ISchemaWrapper.php'
Those stubs are intended for static analysis, not runtime. Once loaded they conflict with the server's implementation:
| Source |
Signature |
vendor/nextcloud/ocp (locked at 720f4bf, 2026-07-21) |
public function getTable($tableName); |
Nextcloud server (master, 35.0.0 beta 1) |
public function getTable(string $tableName): ITable; |
This raises a fatal error and occ app:enable libresign fails. Every following occ libresign:* call then fails with "There are no commands defined in the libresign namespace".
Workaround:
composer install --no-dev --no-scripts
composer dump-autoload -o --no-dev
occ app:enable libresign
After this the 11 libresign:* commands register, the three libresign:install steps succeed, and libresign:configure:check reports success for all six resources (java, jsignpdf, pdftk, poppler, imagick, openssl-configure).
3. setup.sh reports success regardless
setup.sh has no set -e and does not check exit codes, so none of the failures above stop it or affect its exit status. On a completely broken install it still prints:
and exits 0. This is what makes the first two problems hard to diagnose.
Verification
Reproduced on two independent stacks, from separate clones with separate Docker volumes:
|
Stack A |
Stack B |
| PHP |
8.3 |
8.3 (8.2 default cannot install at all) |
| Composer/npm cache volumes |
isolated |
stock (host ~/.composer, ~/.npm) |
setup.sh exit code |
0 |
0 |
| Fatal errors |
1 |
1 |
| "no commands defined" |
4 |
4 |
| App state afterwards |
Disabled |
Disabled |
libresign:* commands |
0 |
0 |
Binaries in appdata |
none |
none |
I'm happy to open a PR for any or all three once you indicate which approach you prefer — particularly for #2, where pinning nextcloud/ocp to the server version and installing with --no-dev are meaningfully different choices.
Expected behavior
Following .devcontainer/README.md on a clean checkout should produce a working LibreSign instance, and setup.sh should fail loudly when a step fails instead of reporting success.
Screenshots
No response
Operational System
Linux (Debian 13), Docker 29.7.2, Docker Compose v5.4.0. Images ghcr.io/librecodecoop/nextcloud-dev-php82:latest (default, fails) and :php83 (used for the rest of the investigation).
Browser Type and Version
Not applicable — all failures occur during CLI setup.
Libresign Version
15.0.0-dev.1 (main, commit 0f6ffdad0)
Nextcloud Server Version
35.0.0 beta 1 (VERSION_NEXTCLOUD=master, the devcontainer default)
Logs from Nextcloud Server
Failure 1 — docker compose logs nextcloud, repeating indefinitely:
usermod: no changes
⌛ Waiting for database 🐬mysql
✅ Database 🐬mysql ready
⌛️ Starting installation ...
This version of Nextcloud requires at least PHP 8.3<br/>You are currently running 8.2.33. Please update your PHP version.❌ Installation failed. Check the logs above for the exact reason.
If this is a local reset issue, remove: volumes/mysql/data, volumes/nextcloud/config and volumes/nextcloud/data
Failures 2 and 3 — output of setup.sh, immediately after composer dump-autoload -o:
> composer dump-autoload -o
Generating optimized autoload files
Generated optimized autoload files containing 3242 classes
PHP Fatal error: Declaration of OC\DB\SchemaWrapper::getTable(string $tableName): OCP\DB\Schema\ITable must be compatible with OCP\DB\ISchemaWrapper::getTable($tableName) in /var/www/html/lib/private/DB/SchemaWrapper.php on line 76
There are no commands defined in the "libresign" namespace.
There are no commands defined in the "libresign" namespace.
There are no commands defined in the "libresign" namespace.
There are no commands defined in the "libresign:configure" namespace.
Updated name to LibreSign
...
✍️ LibreSign is up!
The three libresign namespace errors correspond to the --java, --pdftk and --jsignpdf install steps; the fourth is libresign:configure:openssl.
Logs from Developers tools
Not applicable.
Additional context
On one of three docker compose up runs with empty volumes, the nginx container also failed to start:
error mounting "/…/libresign" to rootfs at "/var/www/html/apps-extra/libresign":
create mountpoint for /var/www/html/apps-extra/libresign mount: read-only file system
nginx mounts /var/www/html read-only and cannot create the apps-extra/libresign mountpoint before the nextcloud container has populated the volume. Starting nginx again after Nextcloud finishes initializing works. It only reproduced once in three attempts, so it looks like a startup race rather than a deterministic failure. Happy to open it separately if useful.
Describe the bug
The devcontainer does not produce a working environment on a clean setup, and
setup.shexits 0 with✍️ LibreSign is up!while LibreSign is left disabled and no dependencies are installed.To reproduce
From a clean checkout of
main(0f6ffdad0) with no pre-existing Docker volumes, following.devcontainer/README.md.There are three independent failures, chained — each one only becomes visible after the previous is worked around.
1. Default
PHP_VERSIONis incompatible with the Nextcloud version pulleddocker-compose.ymldefaults toghcr.io/librecodecoop/nextcloud-dev-php${PHP_VERSION:-82}whileVERSION_NEXTCLOUDdefaults tomaster(currently 35.0.0 beta 1), which requires PHP 8.3:Because the service is declared
restart: unless-stopped, the container retries forever. From the outside this looks like a hang rather than a failure — the error only appears indocker compose logs nextcloud.composer.jsonalready declares"platform": {"php": "8.3"}, so the compose default appears to have fallen behind.Workaround:
PHP_VERSION=83.2.
nextcloud/ocpstubs shadow the server's own classesWith the environment able to boot,
setup.shrunscomposer install(line 17), which installs dev dependencies includingnextcloud/ocp. Thepost-install-cmdhook then runscomposer dump-autoload -o, registering theOCP\namespace from the app's vendor directory into the optimized classmap:Those stubs are intended for static analysis, not runtime. Once loaded they conflict with the server's implementation:
vendor/nextcloud/ocp(locked at720f4bf, 2026-07-21)public function getTable($tableName);master, 35.0.0 beta 1)public function getTable(string $tableName): ITable;This raises a fatal error and
occ app:enable libresignfails. Every followingocc libresign:*call then fails with "There are no commands defined in the libresign namespace".Workaround:
After this the 11
libresign:*commands register, the threelibresign:installsteps succeed, andlibresign:configure:checkreportssuccessfor all six resources (java, jsignpdf, pdftk, poppler, imagick, openssl-configure).3.
setup.shreports success regardlesssetup.shhas noset -eand does not check exit codes, so none of the failures above stop it or affect its exit status. On a completely broken install it still prints:and exits
0. This is what makes the first two problems hard to diagnose.Verification
Reproduced on two independent stacks, from separate clones with separate Docker volumes:
~/.composer,~/.npm)setup.shexit codelibresign:*commandsappdataI'm happy to open a PR for any or all three once you indicate which approach you prefer — particularly for #2, where pinning
nextcloud/ocpto the server version and installing with--no-devare meaningfully different choices.Expected behavior
Following
.devcontainer/README.mdon a clean checkout should produce a working LibreSign instance, andsetup.shshould fail loudly when a step fails instead of reporting success.Screenshots
No response
Operational System
Linux (Debian 13), Docker 29.7.2, Docker Compose v5.4.0. Images
ghcr.io/librecodecoop/nextcloud-dev-php82:latest(default, fails) and:php83(used for the rest of the investigation).Browser Type and Version
Not applicable — all failures occur during CLI setup.
Libresign Version
15.0.0-dev.1 (
main, commit0f6ffdad0)Nextcloud Server Version
35.0.0 beta 1 (
VERSION_NEXTCLOUD=master, the devcontainer default)Logs from Nextcloud Server
Failure 1 —
docker compose logs nextcloud, repeating indefinitely:Failures 2 and 3 — output of
setup.sh, immediately aftercomposer dump-autoload -o:The three
libresignnamespace errors correspond to the--java,--pdftkand--jsignpdfinstall steps; the fourth islibresign:configure:openssl.Logs from Developers tools
Not applicable.
Additional context
On one of three
docker compose upruns with empty volumes, thenginxcontainer also failed to start:nginxmounts/var/www/htmlread-only and cannot create theapps-extra/libresignmountpoint before thenextcloudcontainer has populated the volume. Startingnginxagain after Nextcloud finishes initializing works. It only reproduced once in three attempts, so it looks like a startup race rather than a deterministic failure. Happy to open it separately if useful.