Posts by aptalca

I'm afraid I don't follow.

Jellyfin has its own users, it doesn't rely on system users. The first time you visit its gui, you go through a wizard to create the jellyfin admin user.

Linuxserver's docker addons do not run as root. They run as user nobody on LE. But that has nothing to do with the user password used in jellyfin gui.

Quote from Peter517

I looked in the /etc/passwd, which contains basic information about each user, such as the username, user ID (UID), group ID (GID).

I don't follow this part. Are you looking inside the container?

With the addon, you simply install it from the repo, wait a bit for it to download the image and create the container, and then you visit http://serverip:8096 in a browser to go through the wizard.

The uid/gid setting is only needed if you're accessing existing media on a remote share and you need to match the perms. Otherwise you don't need to change anything.

1. Is your smb mount read only?

If not, that visiting kid can delete all your media through kodi's file manager.

2. Is your smb mount only providing media access?

If not, that visiting kid can access all the other sensitive stuff on your nas via the file manager.

Those have nothing to do with how the credentials are stored.

If your answer is yes to both, then the credentials potentially being read would be not that big of a deal as that kid can already access all the contents through the file manager.

The only issue I can see is if you reuse the same credentials so the kid being able to see the credentials causes other issues. But that's also a no no. Never use the same credentials for different things.

All in all, I don't really see a significant security issue here. Whoever can see the credentials don't really need the credentials because they can already access those things.

I believe you can protect the kodi interface with a pin (not 100% sure) but in any case, whoever you trust with access to your libreelec box, you're already trusting with access to the media on smb. Make sure it's read only to be safe.

Quote from heitbaum

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.heimdall

That'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?

Comparing master...aarch64 · linuxserver/libreelec-addon-repo

Contribute to linuxserver/libreelec-addon-repo development by creating an account on GitHub.

github.com

Thanks

Great point. Thanks

Quote from chewitt

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.