diff --git a/server_nas08.md b/server_nas08.md
index a5f3ae5..ba8ff87 100644
--- a/server_nas08.md
+++ b/server_nas08.md
@@ -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.