From b5a7328a278e769b36b65306f0dfb1aea1e6084c Mon Sep 17 00:00:00 2001 From: Amritanshu Date: Fri, 16 Oct 2026 15:57:45 +0530 Subject: [PATCH] Say what a missing webroot looks like, and stop pointing at a removed failure The failure that prompted this is the environment file being absent: Error: parsing file ".../nextcloud.env": ... no such file or directory nextcloud.service: Main process exited, code=exited, status=125/n/a The play creates that file before it installs or starts anything, so this cannot come from a play run: it is a start outside one, after ~/podman-data/nextcloud was removed. The unit is WantedBy=default.target, so it retries at boot and fails the same way until the play is run again. The readme now says so, because the fix is not obvious from a 125. The rescue message was also stale: it sent readers to look for "Permission denied" under /usr/local/etc/php/conf.d, which was the PHP session file this playbook no longer creates or mounts, and it had lost the reset-failed hint when the message was shortened. It now names the failure that actually happens (a removed webroot), keeps the database/cache/image pointers that are still real, and gives the command for a unit left failed by an earlier attempt. --- nextcloud/readme.md | 6 ++++++ nextcloud/roles/nextcloud/tasks/main.yaml | 10 +++++++--- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/nextcloud/readme.md b/nextcloud/readme.md index 9cdc587..d50de65 100644 --- a/nextcloud/readme.md +++ b/nextcloud/readme.md @@ -262,6 +262,12 @@ systemctl --user reset-failed nextcloud.service ## Notes and gotchas +- **The environment file is state, and it lives inside the webroot.** So is the + code, `config.php` and `data/`. Removing `~/podman-data/nextcloud` therefore + leaves a unit that cannot start — `parsing file .../nextcloud.env: no such file + or directory`, exit status 125 — and because the generated unit is + `WantedBy=default.target` it will also fail that way at boot. Re-run the playbook: + it recreates the directory, the environment file and the container. - **`activating` is not a healthy state.** A crash-looping container spends its time `activating` between restarts, so the play waits on `status.php` rather than on `is-active`, and reports the journal on failure. diff --git a/nextcloud/roles/nextcloud/tasks/main.yaml b/nextcloud/roles/nextcloud/tasks/main.yaml index 3b1459c..dc2ccd2 100644 --- a/nextcloud/roles/nextcloud/tasks/main.yaml +++ b/nextcloud/roles/nextcloud/tasks/main.yaml @@ -89,9 +89,13 @@ - name: Fail ansible.builtin.fail: msg: >- - Nextcloud is not serving — see the diagnostics above. A "Permission - denied" under /usr/local/etc/php/conf.d, anything about `db` or `redis`, - and "downgrading is not supported" each point somewhere different. + Nextcloud is not serving — the reason is in the diagnostics above. + `no such file or directory` for nextcloud.env or a path under + /var/www/html means this host's webroot was removed without re-running + this play, and anything about `db`, `redis` or "downgrading is not + supported" points at the database, the cache or the image instead. If + the unit is in the `failed` state from an earlier attempt: + systemctl --user reset-failed {{ unit_name }} # Nextcloud wants `cron.php` every five minutes. This has to be *this user's* # crontab, not root's: root cannot `podman exec` into another user's rootless