Page uploads fail with permission denied: CIFS volumes mounted without uid=1654 (reads work, writes fail) #81

New issue

Closed

opened 2026-08-16 16:04:44 +02:00 by matikane · 0 comments

matikane commented

2026-08-16 16:04:44 +02:00

Member

Since the 2026-08-15/16 app update, new page uploads fail while all reads work.

Symptom (production log, 2026-08-16 15:32):

fail: UploadPagesUseCase[0] Failed to upload pages to variant 7eba…; rolling back transaction and cleaning up 0 orphaned image(s)
System.UnauthorizedAccessException: Access to the path '/app/data/images/db/dbcb1c57….jpg' is denied.
 ---> System.IO.IOException: Permission denied
   at FilesystemImageStorage.SaveAsync … line 23

GET /api/images/… → 200 in the same minute; the app runs as uid 1654 (id in the container confirms).

Root cause: the three external media volumes (doujinshi_images, doujinshi_thumbnails, doujinshi_backup) are local-driver volumes with type=cifs (NAS share //192.168.68.80/Doujinshi/…), created without uid=/gid= mount options. The kernel therefore presents every file and directory as root:root with fake 0755 modes — readable by all, writable by none except root. chown -R 1654:1654 is a silent no-op on CIFS (exits 0, changes nothing — verified with a probe file). Writes worked until 2026-08-10 because the container ran as root; PR #66's uid-1654 image broke every write to these volumes, with thumbnails and VACUUM INTO backups failing silently in parallel.

Why the documented repair didn't apply: DEPLOYMENT.md §8.1 covers chown repairs for bind mounts and daemon-local volumes; CIFS-backed volumes ignore chown entirely — ownership is fixed at mount time. The docs also only showed the type=none bind variant in §4.1, not the CIFS layout production actually uses.

Fix (applied in production 2026-08-16, verified):

Stop + remove the container (it holds the volume references).
docker volume rm + docker volume create each media volume with uid=1654,gid=1654,file_mode=0644,dir_mode=0755 in the -o options (same share, same data — only the volume object is rebuilt).
Redeploy the stack (Portainer) → mounts come back owned by 1654; upload, thumbnail generation, and backups verified working.

Docs PR documents the mount options in §4.1, adds §8.1 item 4 (CIFS ≠ chown-able; recreate with uid/gid), and a troubleshooting row for the read-works-write-fails fingerprint.

Since the 2026-08-15/16 app update, new page uploads fail while all reads work. **Symptom** (production log, 2026-08-16 15:32): ``` fail: UploadPagesUseCase[0] Failed to upload pages to variant 7eba…; rolling back transaction and cleaning up 0 orphaned image(s) System.UnauthorizedAccessException: Access to the path '/app/data/images/db/dbcb1c57….jpg' is denied. ---> System.IO.IOException: Permission denied at FilesystemImageStorage.SaveAsync … line 23 ``` GET /api/images/… → 200 in the same minute; the app runs as uid 1654 (`id` in the container confirms). **Root cause**: the three external media volumes (`doujinshi_images`, `doujinshi_thumbnails`, `doujinshi_backup`) are `local`-driver volumes with `type=cifs` (NAS share `//192.168.68.80/Doujinshi/…`), created **without `uid=`/`gid=` mount options**. The kernel therefore presents every file and directory as `root:root` with fake `0755` modes — readable by all, writable by none except root. `chown -R 1654:1654` is a silent no-op on CIFS (exits 0, changes nothing — verified with a probe file). Writes worked until 2026-08-10 because the container ran as root; PR #66's uid-1654 image broke every write to these volumes, with thumbnails and `VACUUM INTO` backups failing silently in parallel. **Why the documented repair didn't apply**: DEPLOYMENT.md §8.1 covers chown repairs for bind mounts and daemon-local volumes; CIFS-backed volumes ignore chown entirely — ownership is fixed at mount time. The docs also only showed the `type=none` bind variant in §4.1, not the CIFS layout production actually uses. **Fix** (applied in production 2026-08-16, verified): 1. Stop + remove the container (it holds the volume references). 2. `docker volume rm` + `docker volume create` each media volume with `uid=1654,gid=1654,file_mode=0644,dir_mode=0755` in the `-o` options (same share, same data — only the volume object is rebuilt). 3. Redeploy the stack (Portainer) → mounts come back owned by 1654; upload, thumbnail generation, and backups verified working. **Docs PR** documents the mount options in §4.1, adds §8.1 item 4 (CIFS ≠ chown-able; recreate with uid/gid), and a troubleshooting row for the read-works-write-fails fingerprint.

matikane referenced this issue from a pull request that will close it,

2026-08-16 16:04:55 +02:00

docs: pin CIFS volume ownership at mount time (uid=1654) #82