Jellyfin docker container - Access to the path '/etc/resolv.conf' is denied

    Zitat von Soma

    Bring the container down and delete the config folder.


    Launch again the container to recreate the config folder.


    Check the permissions again

    Same result, also rebooted the host after deleting jellyfin folders

    Zitat von Zoki

    Soma I do not think, /etc is bound to /config in the container. In the command I gave above, no volume was binded into the container and resolv.conf hab wrong permissions.


    Something weird must be going on.


    messier63 can you try with a different container:

    Code
    docker run --rm -it debian ls -lah /etc/resolv.conf

    See below, the result is the same as jellyfin.

    Code
    Unable to find image 'debian:latest' locally
latest: Pulling from library/debian
6aefca2dc61d: Pull complete
Digest: sha256:6846593d7d8613e5dcc68c8f7d8b8e3179c7f3397b84a47c5b2ce989ef1075a0
Status: Downloaded newer image for debian:latest
-rw-r----- 1 root root 618 Apr 27 13:24 /etc/resolv.conf
    Zitat von Zoki

    Soma I do not think, /etc is bound to /config in the container. In the command I gave above, no volume was binded into the container and resolv.conf hab wrong permissions.


    Something weird must be going on.


    messier63 can you try with a different container:

    Code
    docker run --rm -it debian ls -lah /etc/resolv.conf

    You're right but since op had started several times the container with mixed setups on the YML, usually it's better to start clean.


    With jellyfin I don't see why there should be issues with the resolv.conf


    Unless a corrupted image has been downloaded.


    I'm on phone now but maybe I can try to relaunch it when I get home

    • Offizieller Beitrag

    Soma is right. You need to start with a fresh install of Jellyfin. Since you are using Stacks you need to:

    1. In Portainer stop the Jellyfin container if it is running, and delete it.
    2. Go into images and delete the unused Jellyfin image.
    3. From your Shared folders you need to delete your config folder at dockerappdata/jellyfin.
    4. Adjust your stack. Comment out the lines that Soma mentioned above.
    5. Redeploy in Stacks.

    messier63 Something is wrong with your docker installation. The problem is not related to the jellyfin image, as the permissions are wrong for the debain contaienr too.


    What are you running OMV / debian on and how did you install docker?

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    Zitat von Agricola

    Soma is right. You need to start with a fresh install of Jellyfin. Since you are using Stacks you need to:

    1. In Portainer stop the Jellyfin container if it is running, and delete it.
    2. Go into images and delete the unused Jellyfin image.
    3. From your Shared folders you need to delete your config folder at dockerappdata/jellyfin.
    4. Adjust your stack. Comment out the lines that Soma mentioned above.
    5. Redeploy in Stacks.

    I've done steps 1 to 5 and same result. I think my installation is completely messed up somehow


    Zitat von Zoki

    messier63 Something is wrong with your docker installation. The problem is not related to the jellyfin image, as the permissions are wrong for the debain contaienr too.


    What are you running OMV / debian on and how did you install docker?

    I'm running;

    OMV Version: 6.0.22-1 (Shaitan)

    Processor: Intel(R) Pentium(R) Gold G7400T

    Kernel: Linux 5.16.0-0.bpo.4-amd64


    To install docker, I used the install option via omv-extras

    Did you move the docker root folder to some disk?

    If yes:

    • what file system
    • does the directory have special permissions

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    Zitat von Zoki

    Did you move the docker root folder to some disk?

    If yes:

    • what file system
    • does the directory have special permissions

    My docker files are on my OS SSD drive which has been partitioned into two volumes; one for OMV the other for docker.

    The partition for docker is nvme0n1p4 259:4 0 100G 0 part /srv/dev-disk-by-uuid-7655cb82-5790-4f01-a9a0-42688f930df5 from below. It


    Code
    nvme0n1
├─nvme0n1p1 vfat        FAT32            C734-6663                               509M     0% /boot/efi
├─nvme0n1p2 ext4        1.0              50f3acc7-ebc6-42f0-9245-0eff87d18623   12.7G    20% /
├─nvme0n1p3 swap        1                033dca22-5645-4359-8b52-8d97bb8a55ae                [SWAP]
└─nvme0n1p4 ext4        1.0              7655cb82-5790-4f01-a9a0-42688f930df5   89.6G     3% /srv/dev-disk-by-uuid-7655cb82-5790-4f01-a9a0-42688f930df5

    ls lah /srv/dev-disk-by-uuid-7655cb82-5790-4f01-a9a0-42688f930df5 to see, if something is wrong with permissions.

    Just guessing at the moment.

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    Zitat von Zoki

    ls lah /srv/dev-disk-by-uuid-7655cb82-5790-4f01-a9a0-42688f930df5 to see, if something is wrong with permissions.

    Just guessing at the moment.

    Code
    drwxr-xr-x   6 root root  4.0K Apr 27 14:01 .
drwxr-xr-x  12 root root  4.0K Apr 20 00:09 ..
-rw-------   1 root root  9.0K Apr 27 00:47 aquota.group
-rw-------   1 root root  8.0K Apr 27 00:47 aquota.user
drwx--x---+ 13 root root  4.0K Apr 27 00:48 docker
drwxrwsr-x   5 root users 4.0K Apr 27 14:15 dockerappdata
drwxr-xr-x   2 root root  4.0K Apr 27 14:04 dockerscripts
drwx------   2 root root   16K Apr 19 22:45 lost+found

    docker directory looks a bit funny, is it ok in terms of permissions? dockerappdata, where container config files are kept, look ok to me?


    Extra info below


    Code
    # file: srv/dev-disk-by-uuid-7655cb82-5790-4f01-a9a0-42688f930df5/docker
# owner: root
# group: root
user::rwx
group::--x
other::---
default:user::rwx
default:group::rw-
default:other::---
    Code
    getfacl: Removing leading '/' from absolute path names
# file: srv/dev-disk-by-uuid-7655cb82-5790-4f01-a9a0-42688f930df5/dockerappdata/
# owner: root
# group: users
# flags: -s-
user::rwx
group::rwx
other::r-x
    • Offizieller Beitrag

    Isn’t an “s” under users an ACL permission? I never have understood ACL’s very well, but have learned not to use them on a Linux server unless I knew exactly what they were for. I’m pretty sure you need to remove that so that your appdata permissions looks likedrwxrwxr-x.

    The s in dockerdata is just the SGID bit which makes all files created in this directory owned by group users. May be usefull if the directories are shared using smb.


    I think the problem are the ACLs on the docker directory.

    Code
    drwx--x---+ 13 root root  4.0K Apr 27 00:48 docker

    Check them with:

    getfacl /srv/dev-disk-by-uuid-7655cb82-5790-4f01-a9a0-42688f930df5/docker


    The group default is ---.


    How many containers do you have running? One could try to remove the ACLs*) on the docker directory and hope nothing breaks. The save option is to

    1. uninstall docker,
    2. remove the ALCs from the docker directory,
    3. remove all the contents from the docker directory
    4. re-install docker using the UI.

    One should not use shared folders to create the docker directory.


    *) remove ACLs: setfacl -R -b /srv/dev-disk-by-uuid-7655cb82-5790-4f01-a9a0-42688f930df5/docker which may work if nothing has been destroyed so far.


    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    Gefällt mir 2
    • Offizieller Beitrag
    Zitat von Zoki

    One should not use shared folders to create the docker directory.

    This is what I was going to touch on..


    I create my docker directory in shared folders.. however a couple things I've noticed over the years..


    1. That folder should be a top directory (ie, just under the UUID) and not a sub directory elsewhere. When I tried to make it a subdirectory, I got constant permission issues.


    2. That folder should also not be served over SMB, NFS, etc. There's no useful purpose for it and all it does again is start wrecking permissions.


    I'm with Zoki on how to fix this.


    Uninstall docker in the webUI.

    Delete your docker containers folder from both the webUI and CLI

    Now at the command line, cd to the UUID where you want the docker folder

    mkdir folder_name


    Just as an example, here's where I keep my containers.

    Code
    root@openmediavault:/srv/dev-disk-by-uuid-408aa422-44c0-40d4-8e38-5c1f5ee1a56b/containers#

    In the webUI, go to omv-extras/docker, put the absolute path to your new containers folder there and click save.


    When its done saving, click Install.


    Then see if you can install Jellyfin (I'd also recommend deleting any jellyfin /config folder to remove any issues that may be getting overlooked there).


    If that doesn't work, you might just go ahead and try Emby. They set up practically exactly the same, it's still free as long as you aren't paying for their premier service. My issue with jellyfin has never been in not working, it has been the abysmally slow scans. I've complained on their subreddit and I get a myriad of reasons on why it's slow, and a "it's going to get fixed". As of about 6mo ago last time I tried it... it wasn't. This (for whatever reason) has never been an issue for me with Emby.

    Hi all,


    I started docker all over again and things seem to be working so far. I ran an apt-clean via OMV GUI and deleted the docker folder. Also this time around I allowed OMV to create the folder itself rather than doing it via putty previously.

    From below we see that the + is gone from the docker folder.


    Before reinstall

    Code
    drwxr-xr-x   6 root root  4.0K Apr 27 14:01 .
drwxr-xr-x  12 root root  4.0K Apr 20 00:09 ..
-rw-------   1 root root  9.0K Apr 27 00:47 aquota.group
-rw-------   1 root root  8.0K Apr 27 00:47 aquota.user
drwx--x---+ 13 root root  4.0K Apr 27 00:48 docker
drwxrwsr-x   5 root users 4.0K Apr 27 14:15 dockerappdata
drwxr-xr-x   2 root root  4.0K Apr 27 14:04 dockerscripts
drwx------   2 root root   16K Apr 19 22:45 lost+found

    After reinstall

    Code
    drwxr-xr-x  6 root root  4.0K Apr 27 22:36 .
drwxr-xr-x 12 root root  4.0K Apr 20 00:09 ..
-rw-------  1 root root  9.0K Apr 27 00:47 aquota.group
-rw-------  1 root root  8.0K Apr 27 00:47 aquota.user
drwx--x--- 13 root root  4.0K Apr 27 22:36 docker
drwxrwsr-x  3 root users 4.0K Apr 27 22:54 dockerappdata
drwxr-xr-x  2 root root  4.0K Apr 27 14:04 dockerscripts
drwx------  2 root root   16K Apr 19 22:45 lost+found


    Also previously i was asked to run the commands below which should have yielded -rw-r--r-- for /etc/resolv.conf. Now i am getting the same result whilst previoously i was getting -rw-r----- for /etc/resolv.conf.

    Code
    $ docker run --rm -it --entrypoint="/bin/sh" lscr.io/linuxserver/jellyfin
# ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 59 Apr 27 12:17 /etc/resolv.conf
# exit
$

    So in conclusion the issue seems to boil down to permission issues. and in particular the + for the docker folder?

  • messier63

    Hat das Label gelöst hinzugefügt.
    Zitat von messier63

    So in conclusion the issue seems to boil down to permission issues. and in particular the + for the docker folder?

    Yes, the + indicates, some ACLs are set for this directory.


    docker uses this folder to store the container images, their volumes and other docker internal stuff.

    When you start a container, there is the read-only contents of the image and an additional read-write layer on top of it (highly simplified). The additional read write layer is stored in docker/volumes/<some uid>.

    During the start up of the container docker creates some network config (/etc/resolv.conf beeing one of this) and places it in the read-write layer.


    In your case the read write layer was affected by the ACL on the parent docker directory which were inherited. So docker was trying to set 644, but the ACL did not allow this.


    Lesson learned: Do not put ACLs on the docker root directory.

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    Danke 1 Gefällt mir 1

    Zoki

    Well spotted. This kind of issue comes due to most of the time, people are following instructions from "all over the place" and most of the times, it is told to make a "shared folder" for "docker root" or "container appdata".

    This, of course, will set special flags on the folders that shouldn't be there.


    All it is needed is to set the docker path to a name (the folder doesn't even need to exist) for docker to create it with the proper permissions.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden