One breaking change was that the cli arguments need to be defined with 2 hyphens instead of 1.
So if you used -home before, now you need to use --home
One breaking change was that the cli arguments need to be defined with 2 hyphens instead of 1.
So if you used -home before, now you need to use --home
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.
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.
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.
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.
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
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?
Thanks
Great point. Thanks