Jump to content

Windows Docker permissions issue


Pseudomax
Go to solution Solved by Pseudomax,

Recommended Posts

Pseudomax

Hi,

I have recently upgrade my HTPC with Emby Server to better allow transcoding. I had an older ubuntu server that both hosted both the media and emby server. Now I have an intel based windows PC with an SSD. I initially set this up directly on the PC and connected to the old ubuntu server and use it for all storage (including cache to avoid too many read/write actions and shortening the lifespan). Once I had setup SAMBA on the ubuntu server and signed in I had no issue. However, I decided to install Emby Docker container and run it through a VPN given that I use Emby away from home (with appropriate port forwarding). However, since doing this, any write requirements to the ubuntu server fails (both transcoding and cache) fail. I have tried to redo all the users:groups to make sure that they are all correct and it would seem to be the case. However, everytime I try to stream something that needs a buffer or transcoding the logs show that this fails with 'permission denied'.

I have tried a number of things (see the unanswered post on https://stackoverflow.com/questions/71417345/configuring-user-permissions-in-docker-compose for a more extensive summary).

Any thoughts? (I can post logs if helpful but there would seem only to be a 'permission denied' error when I see the action failed).

Link to comment
Share on other sites

Hi there, if you added SMB paths directly into Emby Server in Docker, what i would suggest doing instead is mounting those SMB paths to a local path in the Docker container, and then use that local path in Emby Server. Please let us know if this helps. Thanks.

Link to comment
Share on other sites

Pseudomax

Hi Luke, I may have already tried that (unsuccessfully)? I created a 'Z:' drive in Windows (outside the container) and mapped it to the SMB folder but this had no positive effect...

Perhaps though you have a different suggestion, in which case please share an example and I can try...

Link to comment
Share on other sites

Pseudomax

It is... but I have mapped the individual drives in docker-compose as such already (and this has not worked):

volumes:
  emby-movies:
    driver_opts:
      type: cifs
      o: "user=u,password=p,file_mode=0777,dir_mode=0777,iocharset=utf8,vers=3.1.1,rw,uid=996,gid=998,sec=ntlmssp"
      device: //192.168.1.162/Entertainment/Movies

 

So I was not sure if you were referring to something else like mapping the windows drive to the ubuntu share and then mapping the docker volume to the windows drive (hence asking for an example)...

Link to comment
Share on other sites

Pseudomax

So...

from this post: https://stackoverflow.com/questions/27989751/mount-smb-cifs-share-within-a-docker-container

it would appear that having rw access to a samba share is prevented as a security measure. The way to change this is to use the 

--privileged

flag ... but having added this to the emby container it did not work (for some reason). I have also tried the --cap-add etc found at this link: https://github.com/moby/moby/issues/22197

... but not a solution as yet. I have just thought that I may be able to use a specific SAMBA-Client docker container (https://hub.docker.com/r/johanmeiring/samba-client) and perhaps this will solve things if the author has built in the necessary requirements, but I will need to do some more reading tomorrow to understand how to set this up...

Link to comment
Share on other sites

Pseudomax

Hi,

After a great deal of trial and error ... unfortunately the "error" remains... I am seemingly unable to get the docker image to gain write permissions to the debian server shares using SAMBA/CIFS! Happy to keep trying if someone wants to help me... but for now I will need to go back to a standard Emby Server installation on Windows (without Docker)!

Link to comment
Share on other sites

Q-Droid

An emby server log could be helpful. 

To make sure I understand it's Ubuntu (or Linux) running samba sharing to a Windows PC running Emby in Docker? Docker on Windows is not in my wheelhouse but can think of a few things.

Don't use the CIFS/SMB share for Emby config and databases. Having cache on a network share sort of defeats the purpose of a cache.

I don't know if mapping SMB shares in Windows has the same problems as mounting CIFS type in Linux, such as the need for nobrl.

I would try:

Check the samba server smb.conf and make the user connecting/mounting the share from Windows an admin user for the share, as long as you want to allow full access and control to this share, for example if it's media only for the Emby server. This may fix some of the .Net access errors by giving full control.

Then map the share to a Windows drive and in turn map the drive to the container volume.

Or if mounting the cifs share directly in Docker then add the nobrl mount option along with the others. But DO NOT include the Emby databases in this share or you can run the risk of DB corruption.

 

  • Thanks 1
Link to comment
Share on other sites

Pseudomax

Hi there,

As a summary:

- Ubuntu/Debian server is running to store my media (essentially a bunch of old smaller drivers in an older machine). This is plugged directly into a wired switch on the same LAN as the Windows PC. A dedicated 'storage' folder is in the top folder level, and both the 'Cache' & 'Recording' folders sit under this folder.

- the storage & all sub-folders have the permission '0777' and are owned by emby:emby. This user:group is the same that is listed in the Volumes for Docker-Compose.

- Cache & Recording are both shared via SAMBA (I attached the key settings in the smb.conf file on the Ubuntu/Debian server).

- Emby Server is running in a Windows Docker Container created using Docker-Compose (a redacted version is attached).

- I also attach the embyserver logs to show the 'permission denied' errors scattered throughout...

- Also, I know you see little point in the cache residing on a network PC (even though both are plugged directly in the Switch) I am still keen to limit the use of the SSD that is powering the Windows PC.

Let me know if you have additional thoughts?

Thank you...

docker-compose.yml smb.conf.txt embyserver.txt

Link to comment
Share on other sites

Q-Droid

There is a known issue with the .Net version used in the stable release of the Emby server when CIFS shares are mounted on Linux for Emby to access. The usual workaround on Linux is to add the nobrl mount option in fstab or scripted mount commands. But what you have is pseudo-Linux on Windows using SMB/CIFS shares from a Linux server. I'm not sure what twist this could add or how to work around it.

You can try these one at a time and/or together.

For the [Entertainment] share in smb.conf add the entry below, might have to restart samba:

    admin users = emby

In the docker-compose file add the nobrl mount option to each of the cifs type volumes, "o:" lines.

If either of these work (or both) then you're good to go. If neither works I don't know what else to try.

 

Link to comment
Share on other sites

  • Solution
Pseudomax

@Q-Droid all credit to you! You have fixed it!!

For anyone else who has a similar issue, the 

nobrl

... was the solution. I did a bit more reading and found this post on Docker Forums: https://forums.docker.com/t/a-workaround-for-net-writing-to-cifs-volume-yielding-empty-file-and-access-to-the-path-is-denied/110872 which helped me add nobrl into my Docker-Compose file. Everything worked after that...

I have attached my example docker-compose file that shows this added for any other 'newbies' to docker!

Thank you again for the help... really appreciated!!

(Note: I marked this post as the solution as the second option you suggested was not needed...)

 

docker-compose.yml

Edited by Pseudomax
  • Thanks 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...