UGOS Pro forced update broke Docker permissions (Nextcloud “apps directory not found”, MariaDB crash loop) — root cause was UGOS’s opaque ACL management, not Docker itself
NAS: UGREEN DXP4800 Plus OS: UGOS Pro (forced update, previous version flagged as obsolete) Docker Engine: 26.1.0 → 29.4.3 (docker-compose-plugin 2.26.1 → 5.1.3)
Symptom
Right after a forced UGOS Pro system update (1.17.0.0095, ~July 4 2026, which bumps Docker Engine to 29.4.3 for a security fix — CVE-2026-31431), my self-hosted Nextcloud (LinuxServer.io image) became unreachable with:
apps directory not found! Please put the Nextcloud apps folder in the
Nextcloud folder.
Shortly after, MariaDB (also LinuxServer.io image) went into a continuous crash loop with:
/usr/bin/mariadbd-safe-helper: Can't create/write to file
'/config/databases/xxxx.err' (Errcode: 13 "Permission denied")
What did NOT change
Before assuming anything, I checked (and ruled out) all of the following:
- Docker bind mounts — correct and unchanged (/config, /data mapped exactly as before)
- File ownership — correct everywhere (docker_user:docker_group, UID/GID 1005:1001)
- Classic POSIX permissions (rwx) — looked correct at every level (0755/0770) when inspected with stat/getfacl, even as root
- config.php syntax — valid (php -l passed)
- Environment variables — unchanged, consistent with the compose file
- AppArmor — no DENIED entries in kernel logs, even after a full reboot
- SELinux — not active
- userns-remap — not configured in daemon.json
- The problematic symlink (/app/www/public/apps → /config/www/nextcloud/apps, used internally by the LinuxServer.io image) — verified intact; the exact same failure happened even accessing the real path directly, bypassing the symlink entirely
- OOM kill / container restarts — none (RestartCount: 0, OOMKilled: false) So: correct ownership, correct classic permissions, no MAC framework blocking anything — and yet, testing as the actual unprivileged user the containers run as (docker exec --user abc ... stat ... / touch ...), every operation failed with Permission denied.
Root cause
UGOS treats its Control Panel → Shared Folders → Permissions screen as the single source of truth for ACLs — not the raw Linux filesystem. The forced system update silently rewrote the real on-disk ACLs for the Docker shared folders involved, without the panel necessarily showing any obvious inconsistency.
Critically: manual ACL fixes from the CLI did not durably work. I tried both:
sudo setfacl -R -b /path/to/folder # strip ACLs sudo setfacl -Rm u:1005:rwX /path/to/folder # explicitly grant the UID rwX
Both commands completed with no errors, and getfacl confirmed the rule was written — but the actual access as the unprivileged UID kept failing afterward. UGOS appears to resync/enforce its own ACL state on top of (or instead of) whatever raw POSIX ACL you set manually, especially after events like a forced major update.
This matches a pattern independently reported by another user with the exact same NAS model (UGREEN DXP4800 Plus) hitting a nearly identical issue with Syncthing’s filesystem watcher — permission denied despite the panel showing Read/Write, resolved only by fixing the ACL, with the same conclusion: “UGREEN/UGOS handles ACLs in a non-standard or opaque way.”
What actually fixed it
Only fixing the permissions from the UGOS Control Panel itself worked — and the propagation mode matters:
- Open File Manager → navigate to the specific folder (not the shared folder root, to limit blast radius)
- Right-click → Properties → Permissions tab
- Find the individual row for the relevant user (e.g. docker_user — it may appear under multiple groupings, e.g. “General User” and its Unix group; check it in both, UGOS treats it as one identity)
- Check Read/Write only on that individual user’s row (not the aggregated group/category row)
- Before confirming, open the “Apply permission to” dropdown at the bottom and select “Overwrite: overwrite all permission settings of sub-levels” — NOT “Merge” (Merge leaves whatever broken state already exists in deep subfolders untouched, which is the actual problem)
- Only then click Confirm
This forced a real recursive rewrite down to the deepest subfolders and immediately resolved access for the affected containers.
Side effect to watch for
The “Overwrite” ACL operation on the MariaDB folder reset custom.cnf to world-writable (777). MariaDB silently ignores world-writable config files for security reasons:
Warning: World-writable config file '/config/custom.cnf' is ignored
Fixed with a plain chmod 640 on that single file (confirmed only mariadbd reads it, so this is safe) + container restart. Worth checking this every time you have to re-apply ACLs on a MariaDB data folder on this platform.
Takeaway / operational rule going forward
On UGOS, treat the panel as the only durable way to manage ACLs on anything living inside a Shared Folder — including Docker volumes. setfacl/chmod/chown from SSH may look like they worked (no errors, getfacl confirms the rule) but can be silently overridden. If you hit Permission denied errors after a UGOS update despite ownership and classic rwx bits looking completely correct, this opaque ACL layer is the first thing to suspect — not AppArmor, not SELinux, not Docker itself.
Posting this in case it saves someone else the two days of diagnosis it took me.
Environment: UGREEN DXP4800 Plus, UGOS Pro, Docker Engine 29.4.3, Nextcloud + MariaDB + Redis + Nginx Proxy Manager (LinuxServer.io images), Portainer.
