Plex being able to play a file but failing to delete it is a strong permission clue. Read access and delete/write access are different operations. In the source case, the media lived on a mounted file share, Plex could read it, and deletion returned “There was a problem deleting file.”
The original poster eventually remounted the CIFS share with broad 0777 modes and noperm, which made the directory writable. That demonstrates the problem was in the effective mount/filesystem permission layer, but it is too permissive to present as the preferred permanent configuration.
Container “root” Is Not the Whole Permission Story
The user granted host root access because the Plex container appeared to run as root. A Docker container still reaches a bind-mounted SMB/CIFS filesystem through the host mount's ownership, mode, ACL, and mount options.
Giving host root permission elsewhere does not automatically change how a CIFS mount presents file ownership to the container.
Deleting a File Requires Write Permission on the Parent Directory
On Unix-like filesystems, deleting a file is primarily a directory operation. Plex can therefore read a media file successfully while being unable to remove it because the mounted parent directory is not writable by Plex's effective identity.
Align the Actual Container Identity with the Mount
The community advised matching the Plex container user/group to the host folder ownership. That is a good durable principle, but do not assume Plex always runs with one universal UID.
Inspect the current container configuration and the effective ownership presented by the CIFS mount before changing PLEX_UID/PUID/PGID.
The Source Used 0777 and noperm as a Broad Workaround
The final source post mounted CIFS with options equivalent to:
file_mode=0777,dir_mode=0777,nopermThis can make the share writable by virtually every local identity and disables normal client-side permission checks. It is useful evidence that the mount policy was blocking Plex, but it should not be the first permanent fix.
Prefer a Dedicated Media Identity or Group
A safer design is to mount the share so the files/directories appear owned by the user/group Plex is meant to use, or by a shared media group. Grant write permission only where Plex needs deletion capability.
If Plex should only read most libraries, consider making only specific managed folders writable.
Verify the Plex Volume Mapping Too
Plex should use the container-side media path, while ZimaOS maps that path to the host mount. Current IceWhale documentation explains this host/container relationship.
Use the current ZimaOS Docker path model before editing ownership.
Plex Must Also Allow Media Deletion
Even with correct filesystem permissions, Plex's own library/server settings need to permit deletion where applicable. A filesystem test from the container can separate “Plex setting” from “OS permission” problems.
Test with One Disposable File
Create or copy a small test file into the target media folder, confirm Plex can see it, then delete it through Plex and verify it disappears from the backing share. Do not test permission changes by deleting unique media first.
Plex Delete FAQ
Does Plex reading a file prove it can delete it?
No. Delete requires write permission on the containing directory.
Did chmod/mount mode 0777 work in the source?
The user reported success after a very permissive CIFS remount, but it is not the preferred least-privilege design.
Should host root access alone fix a Plex SMB deletion problem?
No. The effective CIFS mount ownership/mode and the container's identity still determine write behavior.
