The source identifies the real ownership layer correctly: when a container creates a directory inside a mounted ZimaOS folder, the new directory normally inherits the identity and umask behavior of the process running inside the container, not the permissions you hoped the parent folder would force automatically.
That is why a world-writable parent directory can still end up with newly created root:root subfolders at 0755. If the application runs as root and uses a default umask, root-owned child directories are expected unless the image supports PUID/PGID, a specific container user, setgid group inheritance, ACL defaults, or another permission model.
The Source Example Was a Mounted Backup Folder
The user described a path such as:
/media/Daten/Backupwhere newly created subfolders became:
root:root
drwxr-xr-xA non-root user such as UID 999 could then read but not create files in those new child directories.
A 0777 Parent Does Not Force Child Ownership
The parent's write permission allows the container process to create a child. It does not automatically make the child inherit the parent's owner or group unless filesystem/group rules are configured for that behavior.
The creator's UID/GID and the process's umask determine the normal result.
Use PUID/PGID Only When the Container Image Supports Them
Many LinuxServer-style images expose PUID and PGID environment variables. Other images ignore those variables entirely and require Docker's user: field or application-specific settings.
Current IceWhale Syncthing guidance explicitly tells users to query the real ZimaOS user IDs with:
id -u username
id -g usernameand then place those values into the app's PUID/PGID fields.
See the current ZimaOS PUID/PGID example.
umask Controls Which Permission Bits Are Removed at Creation
An app that creates directories with a base mode of 0777 under a typical umask of 022 will produce 0755 directories. A group-collaboration workflow may use a different umask if the application supports it.
Do not set an ultra-permissive umask globally just to fix one app.
setgid Can Help Keep a Shared Group on New Subfolders
On Linux-native filesystems, setting the setgid bit on a shared directory can make newly created children inherit the directory's group. This is useful when multiple services/users intentionally collaborate through one group.
It does not change the creating process's user ID, and it may not behave the same on NTFS/exFAT mounts that emulate Unix ownership through mount options.
Default ACLs Provide More Explicit Inheritance
On filesystems that support POSIX ACLs, default ACL entries can define what permissions new children receive. This is often cleaner than repeatedly running recursive chmod after every backup job.
Whether the current ZimaOS UI exposes a full ACL workflow for a given storage path should be verified before relying on shell-only configuration.
The Source Was a Feature Request, Not an Existing ZimaOS Setting
The author requested a global PUID/PGID control, inheritance toggle, umask handling, setgid support, and recursive-fix GUI. The thread has no IceWhale response confirming those features were implemented.
Do not present the request list as current Settings options.
Fix the App Identity Before Recursively Changing the Whole Disk
If a backup app repeatedly recreates root-owned folders, running chown -R after every job treats the symptom. Configure the container identity/group/umask correctly first, then repair only the affected tree.
Current ZimaOS app settings let users inspect volume mappings and app configuration, while the exact permission variables depend on the image.
Mounted Folder Ownership FAQ
Why can a child folder become root:root under a writable parent?
Because the process inside the container created it as root and the parent directory does not automatically override the creator identity.
Do PUID and PGID work for every Docker image?
No. They are image-specific environment conventions, not universal Docker variables.
Did IceWhale confirm a global permission-inheritance toggle in the source?
No. The thread is a feature request with no implementation confirmation.
