I have looked at buildx a few times, there is a PR in my dev tree for it. It is a bit messy to build, and on my long term backlog.
Do you need to build it? Aren't all those docker binaries (including the plugins) static go based? They might be compatible as is.
Creating via docker run is fine. If you add "--restart=unless-stopped" as a docker argument, the container will start on boot.
Also "-d" will make it run in the background.
Change the port to something else that's not taken
Subfolder proxy is not recommended as it doesn't always work. It often requires app support for base url.
No idea about what kind of cert is used for dns. If web ssl certs are compatible, the instructions for sharing SWAG certs are in the SWAG readme.
We at linuxserver.io no longer recommend portainer. In fact, we highly recommend against it due to various bugs and questionable design choices, which made providing support very difficult.
We removed it from the linuxserver repo.
We recommend and support containers created with docker run or compose.
It reminds me of this: https://www.reddit.com/r/ProgrammerHu…ferthanotheros/
Linux OSes are quite fragmented and hackers like to cast a large net by targeting the most common platforms. If you're using a debian derivative or a red hat distro with systemd, you're more likely to be targeted.
For cli created containers, restart argument determines whether containers are started by the docker daemon on boot or not.
The addons are different because they ate started by systemd, not the docker daemon.
Linuxserver.io repo is included in the official LE repo, so no.
Forum rules are different than policy/rules/decisions about LE's official repo.
LE team decided they did not want to host downloaders in the official repos. They're not banned addons. Just not published in the official repos. That's all. It's a team decision.
Did you try chowning the folder mapped into nginx as nobody?
I wouldn't recommend manually editing the settings.xml. Just edit the addon settings in the gui.
For installing a package, using our package install mod is much easier: https://github.com/linuxserver/do…package-install
Make sure you don't put config folders on remote mounts like smb. It's a recipe for disaster.
The problem is your Heimdall config is trying to map port 80 for it but it is being used by something else on host.
You can either stop that other thing or change Heimdall's port to something else
Check the output of the following:
journalctl -u docker.linuxserver.heimdallThat's great. Thanks for confirming. We'll push the changes shortly.
Can someone make this change locally to the start script on an affected device and confirm it works as expected?
Thanks
Great point. Thanks
All my things are updated to LE12/aarch64 so not volunteering to test .. but there's nothing special about the AMLGX image; it's functionally the same as RPi4 and other SoCs like Allwinner.
Alright, when I have some time, I'll PR the addons so the arm32 devices will attempt to use the arm64 images, which will serve as a stopgap until LE12.
Thanks, yeah, previously the addons were pulling the "latest" tag, which lets docker automatically detect the arch (in your case it would detect it as arm32 and wouldn't find an image since we deprecated them).
I just need confirmation from someone with an rpi and LE 11 so we can make sure it's not specific to amlogic.
It means the kernel is 64 bit, but the OS is 32bit, which includes all the packages, services and processes, including the docker service (that's why I'm surprised the user reported a 64 bit container worked). I mean the container does use the host's kernel so a 64bit kernel would definitely be a requirement, but I would have guessed other docker service related activities would need 64 bit in the userspace as well. I wonder if it's one of those things where some containers work fine, but some don't.
We need some testing before I do a mass update of all the addons.
