Docker

[orbitron 0]

Latest docker image has a new and exciting error...

 

    System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> System.UnauthorizedAccessException: Access to the path '/root/.dotnet/corefx/cryptography/x509stores/ca' is denied. ---> System.IO.IOException: Permission denied

 

I accessed the container directly and that path does not exist.

 

 

emby-server.txt

[alouch 0]

Latest docker image has a new and exciting error...

 

    System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> System.UnauthorizedAccessException: Access to the path '/root/.dotnet/corefx/cryptography/x509stores/ca' is denied. ---> System.IO.IOException: Permission denied

 

I accessed the container directly and that path does not exist.

 

I've just enabled HTTPS and faced the same issue.

After doing some debug, it appears that Dotnet needs write access to the user homedir to write the cert file (not sure if its the RootCA chain only, or the whole SSL cert directly filename is <hash>.pfx).

The problem is that Emby on docker runs with user 99, which doesn't exists in the image, and hence have no homedir, so it defaults to root, but the effective UID (99) won't have write access to /root/ obviously (700 permissions)

 

You can workaround the issue, by doing a chmod on /root, accessing the Emby webserver once (using https), which will result in the creation of the needed files.

 

Then you will want to change the permission back to 701, to authorize /root/ directory search (but not read) which limits potential breaches (but that's a security concern nonetheless from where I stand, so this must be adressed.)

/ # ps -ef
PID   USER     TIME  COMMAND
    1 root      0:00 s6-svscan -t0 /var/run/s6/services
   34 root      0:00 s6-supervise s6-fdholderd
  173 root      0:00 s6-supervise emby-server
  176 root      0:00 sh ./run
  199 99        0:09 /system/EmbyServer -programdata /config -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
  662 root      0:00 sh
  675 root      0:00 ps -ef
/ # cd
~ # pwd
/root
~ # ls -al
total 4
drwx------    2 root     root            26 Jun  8 23:21 .
drwxr-xr-x   19 root     root           243 Jun  8 20:01 ..
-rw-------    1 root     root            87 Jun  8 23:22 .ash_history
~ # chmod 707 .
~ # 
~ # ls -al
total 4
drwx---rwx    3 root     root            41 Jun  8 23:23 .
drwxr-xr-x   19 root     root           243 Jun  8 20:01 ..
-rw-------    1 root     root           106 Jun  8 23:23 .ash_history
drwxr-xr-x    3 99       99              20 Jun  8 23:23 .dotnet
~ #
~ # chmod 701 .
~ # ls -al
total 4
drwx-----x    3 root     root            41 Jun  8 23:23 .
drwxr-xr-x   19 root     root           243 Jun  8 20:01 ..
-rw-------    1 root     root           361 Jun  8 23:54 .ash_history
drwxr-xr-x    3 99       99              20 Jun  8 23:23 .dotnet

~ # ls -al .dotnet/corefx/cryptography/x509stores/ca/
total 4
drwxr-xr-x    2 99       99              58 Jun  8 23:23 .
drwxr-xr-x    3 99       99              16 Jun  8 23:23 ..
-rw-------    1 99       99            1384 Jun  8 23:23 E6A3B45B062D509B3382282D196EFE97D5956CCB.pfx

Edited June 9, 2018 by alouch

[alucryd 315]

Yet another bright idea from Microsoft, really hope this can be overriden with some env variable, definitely not changing perms on /root.

[nobody01 89]

Can we not add a symlinked 755 permissions directory?

[alucryd 315]

Sure, but this is not an all around solution. What if the user emby runs as does exist? Surely the runtime will look for its home directory, which won't be present in the docker image most of the time.

[nobody01 89]

I think in the provided docker image the user is always the same so this wouldn’t matter

[orbitron 0]

Based on what I am reading there are potentially two solutions:

 

1. Change the user Emby runs as in the container to a real user with an actual home directory

2. If changing the user emby runs as to something new doesn't work. We could give bin an actual home directory in /etc/passwd thus it not defaulting to /root/

 

Just some suggestions.

[alouch 0]

the 'nobody' user have UID/GID of 65534, and its homedir is set to /home

 

The obvious would be to change this to UID/GID '99', which are the values used for instanciating the container.

/ # grep nobody /etc/passwd
nobody:x:65534:65534:nobody:/home:/bin/false
/ # ls -al /home/
total 0
drwxr-xr-x    2 nobody   nogroup          6 Apr  3 20:30 .
drwxr-xr-x   19 root     root           243 Jun  8 20:01 ..

I tried this, but it doesn't work. The process is now owned by a named user, but it is still trying to write to /root/....

 

[EDIT] Found the cause (sorry I'm very new to docker, so...)

process uses ENV variables defined in /var/run/s6/container_environment/ and HOME is set to /root

adding "export HOME=/home" at the beginning of the run script did the trick (/etc/services.d/emby-server/run)

Now the .dotnet/.../*.pfx file is written correctly

Edited June 9, 2018 by alouch

[alucryd 315]

The nobody user is not uid:gid 99 on every distribution since systemd-sysusers became a thing, also it's home is "/" for example on Arch Linux. However, if the runtime respects the HOME env var, we're golden. I'll point it to sth like /tmp in the container.

[alouch 0]

I concur.

Simpliest way with minimum changes : just pass the HOME env variable as /tmp when running the container.

 

I just tried and confirm that the runtime respects this setting (didn't want to re-instanciate a new container, so I edited the config.v2.json file).

 

Moreover, the .dotnet folder already exists in /tmp and contains some other files

Thanks alucryd

Edited June 9, 2018 by alouch

[alucryd 315]

Just pushed a new beta with $HOME set to "/tmp", enjoy

[nobody01 89]

Nice work! Just updated and no reported SSL issues anymore!

[strike 2]

I don't know what you guys did but the latest version fixed my issue (unable to login with users signed up with emby connect)

Thanks!

 

Just FYI, this issue is back in the latest stable image. Looks like it's fixed in the beta tho.

[Luke 42077]

Just FYI, this issue is back in the latest stable image. Looks like it's fixed in the beta tho.

 

Please see how to report a problem. Thanks !

[strike 2]

The details are further back in this thread, but I'll repost them if the issue comes back in the next stable. For now, I'll just use the beta since it's fixed there.

[Quiks 15]

 

I've just enabled HTTPS and faced the same issue.

After doing some debug, it appears that Dotnet needs write access to the user homedir to write the cert file (not sure if its the RootCA chain only, or the whole SSL cert directly filename is <hash>.pfx).

The problem is that Emby on docker runs with user 99, which doesn't exists in the image, and hence have no homedir, so it defaults to root, but the effective UID (99) won't have write access to /root/ obviously (700 permissions)

 

You can workaround the issue, by doing a chmod on /root, accessing the Emby webserver once (using https), which will result in the creation of the needed files.

 

Then you will want to change the permission back to 701, to authorize /root/ directory search (but not read) which limits potential breaches (but that's a security concern nonetheless from where I stand, so this must be adressed.)

/ # ps -ef
PID   USER     TIME  COMMAND
    1 root      0:00 s6-svscan -t0 /var/run/s6/services
   34 root      0:00 s6-supervise s6-fdholderd
  173 root      0:00 s6-supervise emby-server
  176 root      0:00 sh ./run
  199 99        0:09 /system/EmbyServer -programdata /config -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
  662 root      0:00 sh
  675 root      0:00 ps -ef
/ # cd
~ # pwd
/root
~ # ls -al
total 4
drwx------    2 root     root            26 Jun  8 23:21 .
drwxr-xr-x   19 root     root           243 Jun  8 20:01 ..
-rw-------    1 root     root            87 Jun  8 23:22 .ash_history
~ # chmod 707 .
~ # 
~ # ls -al
total 4
drwx---rwx    3 root     root            41 Jun  8 23:23 .
drwxr-xr-x   19 root     root           243 Jun  8 20:01 ..
-rw-------    1 root     root           106 Jun  8 23:23 .ash_history
drwxr-xr-x    3 99       99              20 Jun  8 23:23 .dotnet
~ #
~ # chmod 701 .
~ # ls -al
total 4
drwx-----x    3 root     root            41 Jun  8 23:23 .
drwxr-xr-x   19 root     root           243 Jun  8 20:01 ..
-rw-------    1 root     root           361 Jun  8 23:54 .ash_history
drwxr-xr-x    3 99       99              20 Jun  8 23:23 .dotnet

~ # ls -al .dotnet/corefx/cryptography/x509stores/ca/
total 4
drwxr-xr-x    2 99       99              58 Jun  8 23:23 .
drwxr-xr-x    3 99       99              16 Jun  8 23:23 ..
-rw-------    1 99       99            1384 Jun  8 23:23 E6A3B45B062D509B3382282D196EFE97D5956CCB.pfx

Thank you for this post. I was ripping my hair out trying to figure out what i was doing wrong with my pfx cert. After I chmod'd the /root directory, I could FINALLY access on https.

Edited June 12, 2018 by Quiks

[alouch 0]

Thank you for this post. I was ripping my hair out trying to figure out what i was doing wrong with my pfx cert. After I chmod'd the /root directory, I could FINALLY access on https.

Hello, look a few post after, the root cause was identified as being the $HOME env being set to /root, and another solution was given, which is better and simple :-)

You don't need to change perms on /root if you set this env variable to /tmp

This set in the last beta according to Alucryd. So it will probably make it to the next stable too.

[vaise 340]

Newby linux / docker person here. 

I am testing an unraid system to consolidate my old NAS and windows system onto one central system. 

I have knocked up the unraid system on spare parts to test the solution (3 x 3TB, 2 x 4TB, 1 x 256Gb SSD).  All shares and media content is added.

I have added dockers for Emby beta, TVHeadend, sonarr and Deluge.  All that seems to be working fine (cant seem to backup/restore my watched status but that is a different post). 

I am running the TV recordings in parallel - but the guide data is where I am stuck as the FTA guide stuff in Australia is rubbish and all over the place, 

My issue is interpretting the linux instructions I have for my XML TV Guide service (iceTV) into the TVHeadend docker - i.e the xml grabber stuff. 

I dont understand the differences between a linux distro and the docker bit of it - I have raised this to IceTV also - but I only have 1 month of unraid license before I have to pay for it or dump it - There is 23 days left for me to decide one way or another.   

 

The linux instructions state the following - I have put my comments/questions with *** next to them if someone can assist :

 

Install the 'xmltv' package (for example using Ubuntu the command would be 'sudo apt-get install xmltv')

*** I dont think I do this in a docker....  so I am lost here before I start really - I suspect if I had this 'XML grabber' showing in TV Headend I would be OK with the rest.

Download the IceTV XMLTV based grabber from Where can I download the IceTV perl grabber?

*** I have downloaded this script

Copy the grabber script to the '/usr/bin/' folder (or the folder where the rest of the grabber scripts from XMLTV are located) and made it executable ('chmod +x /usr/bin/tv_grab_au_icetv')

*** I dont think I can do this in a docker can I ?  Where would that folder be ?

1. Run the script as the TvHeadend User (*** What is the tvheadend user in the docker ?)
2. By default on Ubuntu this would be 'hts', so its 'sudo su - hts'
3. Then to configure the script 'tv_grab_au_icetv --configure'
4. Enter your email address and password when asked, if you don't already have an IceTV account it will create one for you when configuring the grabber script.
5. Press enter once the channel list has been displayed
6. Restart TvHeadend to have it pick up the new options ('sudo service tvheadend restart')

*** I believe from now on, I would be OK - it is the stuff above here I am uncertain of.

1. Within TvHeadend go to the Configuration tab, then select the "Channel / EPG" subtab, then the "EPG Grabber Modules" tab under that.
2. Look down the list for "Internal: XMLTV: Australia (IceTV)" under the list of grabbers and select it.
3. Ensure that "View level: Expert" is set from the menu on the right hand side (click it to change it to Expert if not already).
4. Under the Parameters list on the right hand side tick the "Enabled" checkbox, then change the Priority to '0'.
5. Click the "Save" button at the top and then "Re-run Internal EPG Grabbers".
6. On the "Channels" tab (once again under "Configuration" and then "Channel / EPG") edit each channel and select the correct IceTV channel in the "EPG Source" field, then click on "Save".

Thanks all and any in advance.

[mastrmind11 722]

@@vaise, not sure which docker you're using for tvheadend, but the one on dockerhub has the guts for epg scraping already built in.  https://hub.docker.com/r/linuxserver/tvheadend/. toward the bottom are instructions for xmltv.

 

btw, i generally stick to dockerhub for all my containers since they're usually far mroe complete and stable than other locations on the internet.  

 

edit:  I do not run this container, so will be of limited use troubleshooting this one, though I know a bit about docker setups.

Edited June 14, 2018 by mastrmind11

[vaise 340]

@@mastrmind11 :

 

Thanks for this reply.  I used the community apps plugin to find plugins/dockers (as that was what was talked about on unraid forums etc).  

Then there were three different tvheadends, I picked the first one from linuxserver's repository.  The other two are mettbrot and binhex.  I notice in the binhex notes that multiple xmltv sources inc xmltv puxml so I may quickly install that one (just stop the other first) and check it out.

 

There are tons of tvheadends on dockerhub.... which one should I use from there ?

 

Cheers.

Edited June 14, 2018 by vaise

[vaise 340]

I re-installed one this morning, now have some grabbers so making some headway.

[vaise 340]

Posted 15 June 2018 - 07:53 AM

@mastrmind11 :

Seems like the issue with the epg grabbers is due to having basic set as the default view in TV headend.  Others reported it in a few forums.  You have to have something higher that basic - even changing the vies from basic to advanced on the screen is no good - immediately after instakll of TVHeadend, change the view up from basic if you wish to see the EPG grabber modules.  Does not help me however - as I dont understand the iceTV instructions for the docker method of tvheadned.  Not to worry - dont want to highjack this emby docker thread with tvheadens stuff.

 

Here is a docker question though - do I NOT update emby from inseide the docker, but wait for someone to release a docker update instead ?

[Luke 42077]

 

 

Here is a docker question though - do I NOT update emby from inseide the docker, but wait for someone to release a docker update instead ?

We update the docker container using docker update mechanisms.

[vaise 340]

Thanks Luke.

Newbie here to the docker stuff though - so which do I do :

 

1 -  I click update as normal in embny running in the emby docker

2 -  or (like happened last week) there was a docker update and after it updates, I was on a later beta.

[Luke 42077]

 

 

1 -  I click update as normal in embny running in the emby docker

There wont' be an update button in Emby. It will just tell you to go back to our website for instructions.

 

So yes #2 is correct.