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?
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
You're running as root, so you shouldn't be having permission issues with writing. Can you browse the locations and read the existing files on the usb disks?
The issue might be due to how the drives are mounted on host
Likely your volume mapping is incorrect. Docker is a sandboxed env. Containers have access only to things that are specifically allowed.
Add this volume mapping: -v /storage:/storage then the entire storage folder on host will be available inside the container at the /storage path
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.
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 updater checks for image updates nightly. When you restart the addon or libreelec, it creates a container based on the new image
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.
Identified the problem. The command above sends it into a restart loop. Now i dont know why that is happening
Remove the restart argument, remove the container, run it again, then check the logs with ”docker logs home-assistant"
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.
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 issuesCode
- -- Logs begin at Thu 2019-04-11 12:28:36 EDT, end at Sat 2020-05-23 12:46:11 EDT. --
- May 23 12:40:13 LibreELEC systemd: Started docker.linuxserver.portainer container.
- May 23 12:40:14 LibreELEC sh: Unable to find image 'portainer/portainer:latest' locally
- May 23 12:40:14 LibreELEC sh: latest: Pulling from portainer/portainer
- May 23 12:40:14 LibreELEC sh: d1e017099d17: Pulling fs layer
- May 23 12:40:14 LibreELEC sh: 860ebb866910: Pulling fs layer
- May 23 12:40:15 LibreELEC sh: d1e017099d17: Verifying Checksum
- May 23 12:40:15 LibreELEC sh: d1e017099d17: Download complete
- May 23 12:40:15 LibreELEC sh: d1e017099d17: Pull complete
- May 23 12:40:16 LibreELEC sh: 860ebb866910: Verifying Checksum
- May 23 12:40:16 LibreELEC sh: 860ebb866910: Download complete
- May 23 12:40:23 LibreELEC sh: 860ebb866910: Pull complete
- May 23 12:40:23 LibreELEC sh: Digest: sha256:4ae7f14330b56ffc8728e63d355bc4bc7381417fa45ba0597e5dd32682901080
- May 23 12:40:23 LibreELEC sh: Status: Downloaded newer image for portainer/portainer:latest
- May 23 12:40:28 LibreELEC sh: 2020/05/23 12:40:28 server: Reverse tunnelling enabled
- May 23 12:40:28 LibreELEC sh: 2020/05/23 12:40:28 server: Fingerprint 0b:97:31:05:a2:81:89:e9:ca:4e:43:68:55:87:af:56
- May 23 12:40:28 LibreELEC sh: 2020/05/23 12:40:28 server: Listening on 0.0.0.0:8000...
- May 23 12:40:28 LibreELEC sh: 2020/05/23 12:40:28 Starting Portainer 1.23.2 on :9000
- May 23 12:40:28 LibreELEC sh: 2020/05/23 12:40:28 [DEBUG] [chisel, monitoring] [check_interval_seconds: 10.000000] [message: starting tunnel management process]
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)
I'll test this on my end once I get my pi back from the other project it's been working on
What device is this on?
It would be helpful if you tell us exactly what happens when you write the LE image to the card and then try to boot with it.
I had no issues. Used the libreelec imager to flash sd, pop it in, turn it on.
Disable the addon, wait 30 seconds, reenable and then check with that command.
You can add "-f" to the end to watch them live
Thank you, this worked for me with docker.linuxserver.jellyfin. How can I add more than one additional mapping?
You can add as many volume directives as you like in that box, "-v /host1:/container1 -v /host2:/container2", etc.