Posts by aptalca

There are docker addons that do nginx/php and mariadb (among many others)

See here: LinuxServer.io docker addons and general docker info

Quote from Alomon

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

Display More

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

I suggest you check out their docs: Overview - Auckland, Singapore, San Francisco | Portainer.io

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

Quote from basilean

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.

Quote from anand0412

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.

Quote from anand0412

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.

Quote from anand0412

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"

Quote from rick.mccombs

Yes

Check the logs with journalctl -u docker.linuxserver.boinc. That should tell you what happened.

Quote from rick.mccombs

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

1. LibreELEC:~ # netstat -l | grep 8080
2. LibreELEC:~ # netstat -l | grep http-alt
3. 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)

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

Quote from jmolinuevo

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.