Posts by aptalca

    You did not say what method (nfs, smb, etc.) and you did not say how they are mounted (systemd?)

    If systemd, set its service to start before the docker service

    Also fyi, linuxserver does not recommend or support config files to reside on remote shares. Media folders however can be on remote shares.

    Linuxserver.io ones can be installed via addons for added convenience and ease of use but you can use any docker image via command line (docker run) or portainer on libreelec (assuming you're using the correct arch)

    Hi,

    Now I'm facing anothher issue. I would like to access my Nextcloud instance via (for example) https://www.domain.duckdns.org:2222.

    For that, I've forwarded port 2222 to port 443 on my router, as Nextcloud and letsencrypt are accessed on port 443. But it doesn't seem to be sufficient, I've got a timeout error when trying to access Nextcloud on port 2222 and even from my local network.

    Where am I wrong? Do I have to change some settings somewhere on nextcloud and/or letsencrypt? Or even to rebuild the containers?

    Thanks

    Nextcloud has its own auto redirects for security purposes and you'll have to modify those in it's config file. You may have to do other stuff on the nginx side but I'm not sure.

    All of that automation was done for port 443, ymmv with a custom port

    One thing is an api key to identified application that consumes service... this is complete different... we are talking a personal (user) key that would enable google to track your privacy (searches, videos you reproduce, etc).
    This practice attempts freedom, I'm not sure why you try to make it looks as it were ok.

    It's a youtube/google restriction (iirc). You can't use their api without an api key. Apis use the api keys to make sure bad actors aren't abusing their api, and they throttle access via keys if needed.

    If you're worried about tracking, open a new Google account and get an api key for it. Or Google online to see if others like you are sharing anonymous api keys.

    You've misunderstood.

    Something must be wrong with my setup then. Libreelec with kodi and home assistant in a docker runs fine and smooth. When I restart libreelec, the HA docker (which I installed using command line) does not get destroyed and recreated.

    Nginx letsencrypt and duck dns gets destroyed and recreated.

    Docker addons are not the same as docker containers you manually create. Addons use systemd to manage the containers in an automated fashion. The destroy/create is part of the automation. It is perfectly fine as docker containers are ephemeral by design. It is how docker is meant to be used. If you ever want to update the homeassistant container you manually created, you will have to destroy and recreate it based on an updated image (manually). Addons do that automatically without user intervention.

    The validation is performed when the container is started for the first time. Nginx won't be up until ssl certs are successfully generated.

    "started for the first time" refers to starting it with no existing persistent data. The persistent data (including the certs) reside in the userdata addon_data folder by default. As long as it's there, certs are not regenerated until they get close to expiration.

    In any case, it sounds like this is a case of the xy problem. Let's focus on the boot delay. I assure you I'm running plenty of docker addons here on an rpi4 with no noticeable delay. The only delay I'm observing is "waiting for network" before kodi starts.

    Check the kodi log to see what's holding things up during boot. Also check the addon logs with journalctl -u docker.linuxserver.letsencrypt and journalctl -u docker.linuxserver.duckdns (you can also try journalctl -u docker.linuxserver.updater).

    With that said, make sure you update your addons and refresh the repos. There was a brief period of time where the addon updater caused a boot delay of about 10 minutes due to a bug in its systemd config. It was fixed shortly after.

    EDIT: As a test, I set up all three containers in question, two as addons and one manually. I even created homeassistant with the same docker run from your other thread, all on an rpi4 with le 9.2.3 and I experience no boot delay at all.

    The docker addons work that way. The containers are created and destroyed when the addon is started and stopped (including during reboot). That is by design, to ensure the containers get updated when there are image updates. It does not however cause delays because container creation takes no more than a second and the image is already local.

    Duckdns is the lightest image/container we provide as it is just curl firing off every 5 minutes via cron. Nginx is also very light. They will run perfectly fine on an rpi4.

    Homeassistant in the other hand is fairly heavy. Not sure how well it runs in a pi, because I don't personally use it.

    There is no reason for you to try and turn off the updater. It works in the background and doesn't slow things down.

    I tried to get this to work on my raspberry pi 4 I left out the lines about Gauc. I'm behind a firewall I thought it would simpler.

    I don't have any experience with docker. There doesn't seem to be any webserver running on 8080.

    Code
    LibreELEC:~ # netstat -l | grep 8080
    LibreELEC:~ # netstat -l | grep http-alt
    LibreELEC:~ # 

    I have Rosetta at home running on my x86_64 computers and I had it on the raspberry pi 4 running Ubuntu, I thought I would try Libreelec on the Raspberry pi4. I've been running OSMC on a Pi 3+.

    Before I go to a lot of trouble to try to get this to work, has anyone got Rosetta at home to send work to there Pi 4 using this docker?

    Did you install it via the addon?

    I'm using libreelec 9.2.1 on an rpi4 and I hit install on the portainer addon and it pulls the image and starts the container with no issues

    It looks like there are two separate issues above. One is an issue with a docker image layer, perhaps a corrupted download? I recommend deleting all images and retrying.

    The other issue Error response from daemon: driver failed programming external connectivity on endpoint portainer (6fe60690b6e31eeb0860e8e8af looks like port 9000 is already in use by something else (upnp?) You can either turn upnp off and try again, or you can change the portainer port in addon settings to anything else (like 9001)