rufusking/infrastructure
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Updated NAS08 ffmpeg manually and added a note

Browse source
This commit is contained in:
Rufus King 2026-07-29 21:52:46 -04:00
parent 2b77c0b7c3
commit fd1025cb1e
1 changed files with 67 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

74
server_nas08.md
View file

@ -843,20 +843,79 @@ All Nextcloud updates must be performed via `occ` on the command line.
- **Email:** HTML report sent daily — green (up to date) / amber (updates available) / red (maintenance mode or DB upgrade needed)
- The email includes a ready-to-paste command block for any action required
### **Manual Update Commands**
Run these on NAS08 whenever the email reports updates available:
```bash
# Update all apps (instead of clicking Update in browser)
sudo docker exec -u www-data nextcloud php occ app:update --all
### **⚠️ Custom `nextcloud-ffmpeg` Image — Required Before Any Core Update**
The `nextcloud` and `cron` services in `nextcloud.yml` do **not** run the stock
`nextcloud:latest` image. They run a locally-built custom image tagged
`nextcloud-ffmpeg:latest` (built 2026-07-28, adds ffmpeg on top of the official Nextcloud
image for video preview generation). This build lives in a **separate, standalone Compose
project** that the main `nextcloud`/`compose.override.yml` files know nothing about:
# After docker compose pull + up (Nextcloud container version update)
sudo docker exec -u www-data nextcloud php occ upgrade --no-interaction
```
/kingdezignsnas/Docker/Compose/nextcloud-ffmpeg-build/
nextcloud-ffmpeg-build.yml
nextcloud-ffmpeg-build.env
```
That project's `Dockerfile` does `FROM nextcloud:latest` and layers on `apt-get install
ffmpeg` (and related packages). The resulting image is tagged `nextcloud-ffmpeg:latest`
and consumed by `nextcloud.yml` via a plain `image:` key (no `build:` block there) — so as
far as `docker compose -f nextcloud.yml pull` is concerned, `nextcloud-ffmpeg:latest` looks
like a normal registry image. It isn't. **Running `pull` in the main `nextcloud` project
without rebuilding this image first will always fail** with `pull access denied for
nextcloud-ffmpeg, repository does not exist` — because Docker Hub has no such public
repository. This failure aborts a `pull && up -d` one-liner (chained with `&&`) before
`up -d` ever runs, silently leaving the **old** container running with the impression that
an update occurred (confirmed 2026-07-29 — `occ status` still reported the pre-update
version after a "successful"-looking pull/up command, because `up -d` never actually ran).
**Correct update order — rebuild the custom image *before* touching the main project:**
```bash
# 1. Rebuild nextcloud-ffmpeg, forcing a genuine fresh nextcloud:latest base pull.
# --no-cache alone is NOT enough — without --pull, the FROM nextcloud:latest layer is
# reused from whatever was already cached locally, so a --no-cache-only rebuild can
# silently rebuild the SAME Nextcloud core version rather than picking up a new one.
sudo bash -c "cd /kingdezignsnas/Docker/Compose/nextcloud-ffmpeg-build && docker compose -f nextcloud-ffmpeg-build.yml --env-file nextcloud-ffmpeg-build.env build --no-cache --pull"
# Note: this project's own trailing `pull` step (if run) will itself fail with the same
# "access denied" error, since it tries to pull the image it just built locally under the
# same tag. This is expected and harmless — safe to ignore, or omit `pull` entirely here.
# 2. Pull the OTHER services in the main project — exclude nextcloud/cron by name,
# since their image is local-only and was just rebuilt in step 1.
sudo bash -c "cd /kingdezignsnas/Docker/Compose/nextcloud && docker compose -f nextcloud.yml -f compose.override.yml pull db onlyoffice autoheal"
# 3. Recreate all containers to pick up the new local image + pulled updates.
# Watch for "Started" (not "Running") on nextcloud/nextcloud_cron to confirm recreation.
sudo bash -c "cd /kingdezignsnas/Docker/Compose/nextcloud && docker compose -f nextcloud.yml -f compose.override.yml up -d"
```
> Because `/kingdezignsnas/Docker/Compose/nextcloud/` is `drwx------ root root`, all
> commands against either project must use `sudo bash -c "cd ... && ..."` — plain `cd` or
> `-f nextcloud.yml` from a non-root shell in another directory will fail with
> "no such file or directory", and `grep`/direct file reads need `sudo` as well.
### **Manual Update Commands**
Run these on NAS08 whenever the email reports updates available — **after** completing the
`nextcloud-ffmpeg` rebuild sequence above:
```bash
# Give the container's built-in upgrade entrypoint time to finish after step 3 above,
# then confirm the new version is active
sleep 30
sudo docker exec -u www-data nextcloud php occ status
# Update all apps (instead of clicking Update in browser)
sudo docker exec -u www-data nextcloud php occ app:update --all
# Verify clean state after any update
sudo docker exec -u www-data nextcloud php occ status
```
> The official Nextcloud image's entrypoint auto-upgrades the core app on container start —
> `occ upgrade` does not need to be run manually in the normal case. Checking status
> immediately after `up -d` can race that internal process; the `sleep 30` above avoids a
> false "old version" reading (see the core-update false-negative fix below for the full
> background on this race).
### **Recovery — If Stuck in Maintenance Mode**
```bash
sudo docker exec -u www-data nextcloud php occ maintenance:mode --off
@ -975,6 +1034,7 @@ run of the script correctly reported "up to date."
- Nextcloud container name: `nextcloud` — cron container: `nextcloud_cron` — DB: `nextcloud_db`.
- **Never update Nextcloud apps via the browser UI** — Apache segfaults mid-update leave Nextcloud stuck in maintenance mode. Always use `occ app:update --all` from the command line.
- **Nextcloud update check script:** `/usr/scripts/omv/nextcloud_update_check.sh` — runs daily at 7AM, emails HTML report with ready-to-paste update commands. SMTP password at `/etc/nextcloud-smtp-pass`.
- **Custom `nextcloud-ffmpeg:latest` image (built 2026-07-28):** The `nextcloud`/`cron` services in `nextcloud.yml` run a locally-built image (`FROM nextcloud:latest` + ffmpeg installed via apt), not the stock Nextcloud image. Built by a separate, standalone Compose project at `/kingdezignsnas/Docker/Compose/nextcloud-ffmpeg-build/` (`nextcloud-ffmpeg-build.yml` + `.env`) that the main `nextcloud`/`compose.override.yml` files do not reference. **This must be rebuilt with `docker compose build --no-cache --pull` BEFORE any `docker compose pull` is run in the main `nextcloud` project** — otherwise `pull` fails on `nextcloud-ffmpeg:latest` ("pull access denied", not a real registry image) and aborts a chained `pull && up -d` command before `up -d` ever runs, silently leaving the old container in place while looking like the update succeeded (confirmed 2026-07-29). `--pull` (not just `--no-cache`) is required on the rebuild to actually fetch a fresh `nextcloud:latest` base — `--no-cache` alone can still reuse an already-cached base layer. See dedicated Update Procedure section above for the full corrected 3-step sequence.
- **Nextcloud update check script — core-update false negative fixed (2026-07-25):** the script previously only checked `occ app:update` (app updates), never `occ update:check` (core/server updates), so a core release like 34.0.2 was invisible and the email falsely reported "up to date." Fixed by adding a core-update check, fixing a `\n`-in-double-quotes bug that made emailed commands unreadable, and correcting the emailed update commands to use the real Compose path (`/kingdezignsnas/Docker/Compose/nextcloud/`, root-only, requires `sudo bash -c` + explicit `-f nextcloud.yml -f compose.override.yml` flags — not the default `docker-compose.yml`/`~/docker/nextcloud` assumed originally). Also documented: the official Nextcloud image auto-upgrades on container restart via its own entrypoint — running `occ upgrade` or checking `occ status` immediately after `docker compose up -d` can race that internal process and falsely show the old version for ~30 seconds. The emailed command block now includes a `sleep 30` before the confirming status check. See dedicated section above for full troubleshooting detail and the mock-harness verification method used to confirm the fix.
- **Maintenance mode recovery:** `occ maintenance:mode --off` → `occ upgrade --no-interaction` → `occ app:update --all` → `occ maintenance:repair`.
- **PLEX32 backup destination:** `/export/kingdezigns-all/Docker/plex/config/backups/` — plex and tautulli subdirs receive tar archives every 3 days. Must be `www-data:ncshare 2770` or writes will fail.