CIFS mount giving permission denied with other user than root

[Ralms]

Ask a Question!

Hi everyone,
I'm running into a weird issue that I was hopping someone could provide me some insights.
I have a container running Plex, which has a CIFS volume attached to it, in Writable mode.
Plex runs on a specific UID and GID, not root, and the issue I'm facing is that Plex is getting Permission denied doing write operations on the CIFS volume.

If I enter the container with a bash console, with the root user (UID 0), I have write permissions fine, but not with any other user.

Considering that the SMB share credentials used in the CIFS volume have Read/Write, the volume is mapped as "writable" confirmed by testing with "root" user on bash console, however failing with any other user with "Permission denied", I don't understand what am I missing.

Any ideas?

Thank you.
(Portainer Business Edition 2.21.1, Ubuntu 22.04.4 host, Docker 27.1.2)

[tesla-srt]

I'd like to bump this.
I just ran into a similar issue and completely derailed my architecture.
If anyone has a solution, please link me 🥂

[Sebtous]

Bump for me as well

[Ralms]

The lack of engagement from the Portainer team after 1 year, is concerning.

[CodingAna]

Same for me. I have been using ytdl for a while and stopped using it in Dec of last year. Started the container again and now I get the same error as mentioned, permission denied for non root user.
Bumping, although I don't expect much after 1.5 years.

[Nick-Portainer]

Sorry for the slow response on this one, it slipped through the cracks for far too long.

This actually does not sound like a Portainer bug, it's how CIFS handles ownership at the kernel level. When the kernel mounts an SMB/CIFS share it presents every file as owned by a single uid/gid that's fixed at mount time. If you don't pass uid/gid options it defaults to root (uid 0), since that's the user that performed the mount. CIFS doesn't map the in-container process UID through to the share the way a local bind mount would.

So when Plex runs as its non-root PUID it's looking at a mount full of root-owned files and write fails. Root works because it matches the mount owner, which is why the bash-as-root test passes and throws you off the scent. The Writable setting and the share's R/W credentials only control whether the mount is rw vs ro at the protocol level, they don't affect which local UID is allowed to write. Two separate things.

The fix is to add uid, gid and mode options so the files surface as owned by your Plex user. In compose that looks like:

volumes:
  plexmedia:
    driver_opts:
      type: cifs
      device: "//your-nas/media"
      o: "username=USER,password=PASS,uid=1000,gid=1000,file_mode=0775,dir_mode=0775,vers=3.0"

Set uid and gid to match the PUID/PGID Plex is running as (the LinuxServer.io image defaults to 1000/1000, but worth confirming yours). If you created the volume through the Portainer UI, those go into the additional CIFS mount options field rather than the credential fields, which is the easy bit to miss.

You can confirm it's nothing to do with Portainer by creating the same volume with a plain docker volume create using identical options. It'll behave exactly the same, because the permission handling all lives in the kernel cifs module and the SMB protocol.

Give that a go and let me know how you get on.