Emby Config path problem

  • Hello,


    I'm running Emby-Server in a docker container without any problems so far. Currently I have mapped the /config folder to /var/lib/embyconfig.
    But now I have tried to put the Config folder away from the system-harddisk to one of my data-harddisk and changed the path to /srv/c0b02455-2ccf-4759-86fb-dcd998242e4a/Docker/embyconfig.


    With this, emby does not start.
    Can someone please help me. Thank you.


    Stefan

    • Offizieller Beitrag

    Yes, I have move all the stuff to the new location. Also, if I try to make a fresh setup from emby with a blank folder, it wont start either.

    Two options, either stop the container and delete, then delete the image and start over, or it's a permissions issue in relation to the new folder and the Emby user does not have read/write access.

  • OK, I have deleted the container and installed new. Same behavior.
    I have created a new shared folder and set the right to everyone read/write and link this one to /config. Same behavior.


    Any suggestions what to try next?


    Stefan


    P.S.
    I have take a look at the new folder: Emby creates all the needed folders inside, but stopped working after about 4 seconds

    • Offizieller Beitrag

    I have created a new shared folder and set the right to everyone read/write and link this one to /config. Same behavior.

    Have you created an Emby user in OMV (mine is named Emby) even though my folders are set to everyone if there is no Emby user it simply won't work. This user was created automatically in previous versions, but because you are using a docker the user has to be created in OMV.

    • Offizieller Beitrag

    no, I have no user named Emby in OMV. Do I have to gave him special rights and/or do I have to add hhim into the config of the emby container in docker?

    It doesn't have to be a user specifically called Emby, that is how I have done mine, add the user (call them Jo, Fred whatever) under Access Rights Management then give then read/write access to the config folder, then when Emby starts add that user name during the Emby wizard set up.

  • Actually the name does not matter, the id has to be the same.
    The common way to go is to decide for a user (might be a new one named emby) on the host and tell the docker image to use this user. Modify the container, not the host is a good rule of thumb.

    • Offizieller Beitrag

    Yes, I do. Is there a problem with?

    :thumbup: Same as me and I found that a problem, but I have six drives in my machine but only four are part of mergerfs + snapraid, so my config is on one of my single drives.


    I have not done any further testing, but the other thing I do not do is to use /sharedfolders I use /srv

    • Offizieller Beitrag

    You think, mergerfs is the reason thats docker container have a problem with?

    Possibly, I had two problems when first setting this up, one was the auto box sets plugins didn't appear to be working, no box sets were being created. The second was nfo files, this was not fully populating the metadata in Emby's gui, so I asked in the Emby forum, turned out it was a permissions issue, but still not box sets!
    So I decided to move the /config to one of my other drives, as soon as I did that (had to scan the library twice) the box sets populated.
    My mergerfs plugin is set to MFS all my shares are created under that single mount point and it works, but for some reason Emby wouldn't work, but you can create a share on a drive within the mergerfs pool, you don't have to use the mergerfs mount point. Would that work? I don't know I haven't tried it.
    I also don't use Emby's metadata scraper I use MCM and all the metadata is kept in each films folder, other than the cast that is stored within the Emby config, but it now all works. One day I might get around to testing some different config set up's but that would mean scanning the library each time.

  • .... but you can create a share on a drive within the mergerfs pool, you don't have to use the mergerfs mount point. Would that work? I don't know I haven't tried it.

    I have tried that with a share out of the mergerfs mountpoint, but with the same result. Restart after 4 seconds. It's annoying...


    Stefan

Jetzt mitmachen!

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