Plex has paywalled my server!
-
That's basically what I do right now except I do have a domain and my ISP doesn't restrict inbound ports like 443 so it works fine.
Just trying to sort out if I want the headache of a VPS if I don't need it (costs, maintenance, point of failure, etc).
Sounds like you don't need the VPS then. Add a subdomain to your home IP. Port forward 443 and 80 to the sever. Run caddy to route the subdomain to localhost:8096. You will also need to tell jellyfin to accept on the new domain.
-
It's pretty rare that a company starts taking away free features and doesn't end up fucking payers in the end.
The biggest bar to Jellyfin is TV clients, the second biggest is security.
TV clients can be fixed with a one-time purchase of a $20 android TV stick. If viewing your familys ARR content isn't worth $20 you probably don't need to do it anyway.
Security for remote streaming is a harder thing to handle. Most people are capable of port forwarding, But just hanging a smallish public project out there in the open is always a dicey proposition. It honestly needs real fail2ban, probably SSL, 2FA and password complexity requirements.
We could probably make a jellyfin helper container to handle some of this. Walk people through Let's Encrypt, dynDNS, port forwarding tests, add fail2ban with a firewall, maybe even slap suricata in it.
We need to convince the project to add 2FA and password complexity requirements.
I don't know guys what do you think is it crazy? does it make sense? Would anybody actually use it?
What are my realistic security concerns with a jellyfin server that I let friends and family watch while trying to minimize the troubleshooting and steps they need to take to get started?
-
What are my realistic security concerns with a jellyfin server that I let friends and family watch while trying to minimize the troubleshooting and steps they need to take to get started?
I would be very interested in an answer to this as well. Also any how to guides that would be useful for a guy whose technical high-water mark was getting mint set up on my laptop.
-
What are my realistic security concerns with a jellyfin server that I let friends and family watch while trying to minimize the troubleshooting and steps they need to take to get started?
realistic security concerns
If you're running a binary installation of Jellyfin on your server and exposing it to the public internet, you can face significant risks:
-
Remote execution vulnerabilities might allow attackers to exploit bugs to run malicious code on your server.
-
Buffer overflows. Poorly handled data can let attackers manipulate memory, Bypass logins, touch things in the host that aren't meant to be twiddled with
-
Network exposure. If compromised, the server could become a launchpad for attacks on your network.
There might not be any vulnerabilities at this moment, but they might come in a future release. And we might not even know they exist. It's a small team of volunteers, and they'll do their best. This is just what is reasonably possible when installing the server as an application on your OS and exposing it to the Internet.
You can minimize risk with a safer setup, as someone else in the comments here mentioned (and I think they even linked to their setup)
Using a Docker container version of the app significantly reduces your attack surface. This isolates the app from your host system. If they get in, they only get into the container and whatever that container is allowed to do.
Mount your media files as read-only to prevent accidental modifications or potential malicious changes. Now that container can't do any real harm do your data.
Avoid making the container privileged. A privileged container can interact with the host system in risky ways.
Use reasonable unique usernames and passwords. If the container does manage to get compromised, they will likely be able to read usernames and passwords stored in the container.
Regularly update your container – Ensures you have the latest security patches.
Short of some massive Docker vulnerability, (which is on you to keep updated) the worst case should be public enumeration of your media, exposure of your JF users/passwords, and denial of service. Which IMO isn't very serious.
For even tighter access control, don't whitelist the entire world.
Whitelist specific IP addresses. Have users visit WhatIsMyIP to get their IP, then configure port forwarding to allow only trusted addresses. This allows the clients at their houses in without any serious hinderance, but would block them from accessing your media when they're not at their house.
If they're accessing you through a phone or PC, setup headscale or tailscale or any VPN and allow them to get to you through VPN
-
-
realistic security concerns
If you're running a binary installation of Jellyfin on your server and exposing it to the public internet, you can face significant risks:
-
Remote execution vulnerabilities might allow attackers to exploit bugs to run malicious code on your server.
-
Buffer overflows. Poorly handled data can let attackers manipulate memory, Bypass logins, touch things in the host that aren't meant to be twiddled with
-
Network exposure. If compromised, the server could become a launchpad for attacks on your network.
There might not be any vulnerabilities at this moment, but they might come in a future release. And we might not even know they exist. It's a small team of volunteers, and they'll do their best. This is just what is reasonably possible when installing the server as an application on your OS and exposing it to the Internet.
You can minimize risk with a safer setup, as someone else in the comments here mentioned (and I think they even linked to their setup)
Using a Docker container version of the app significantly reduces your attack surface. This isolates the app from your host system. If they get in, they only get into the container and whatever that container is allowed to do.
Mount your media files as read-only to prevent accidental modifications or potential malicious changes. Now that container can't do any real harm do your data.
Avoid making the container privileged. A privileged container can interact with the host system in risky ways.
Use reasonable unique usernames and passwords. If the container does manage to get compromised, they will likely be able to read usernames and passwords stored in the container.
Regularly update your container – Ensures you have the latest security patches.
Short of some massive Docker vulnerability, (which is on you to keep updated) the worst case should be public enumeration of your media, exposure of your JF users/passwords, and denial of service. Which IMO isn't very serious.
For even tighter access control, don't whitelist the entire world.
Whitelist specific IP addresses. Have users visit WhatIsMyIP to get their IP, then configure port forwarding to allow only trusted addresses. This allows the clients at their houses in without any serious hinderance, but would block them from accessing your media when they're not at their house.
If they're accessing you through a phone or PC, setup headscale or tailscale or any VPN and allow them to get to you through VPN
Amazing info, thank you for the response!
-
-
What I see in these threads is the reverse. People insist that their pet solution is a panacea for every use case and when someone points out that it doesn't work for them they get downvotes and sarcasm. Making use of the best software for your use case is not equivalent to complicity in animal torture and environmental destruction. Nobody's being forced into constant pregnancy or having their calves taken away at birth because I feel like third party security patches for Windows will be a better option for me than fully swapping to a Linux distro.
But what is definitely happening is people stop reading pro-FOSS threads by the third rabid fanboy response and actually miss what could be a useful alternative.
If one limits their scope to the nutrients or taste of food on their plate then they wouldn't consider the well-being of other conscious creatures. Only considering system requirements to complete an activity misses out the freedom of the user(s), apparently.
It is a given that humans suffer due to the unjust power that proprietary software gives devs over their user's computing. Even the best dev does not the the willpower to always resist the temptation to use that power at the expense of the users. Many devs are oblivious they are doing anything wrong and many are malicious/anti-consumer.
There is also the impact it's use and promotion has on others - money/feedback/promotion given to the non-free projects are boons not given to the freedom-respecting projects. I am better off when others start to move away from proprietary software.
-
Give me a package that runs on my ds214play and I'll switch in a heartbeat
https://github.com/SynoCommunity/spksrc/issues/5941 ?
I really wanted Jellyfin working in my DS214Play with DSM6, and I noticed that a package for these evansport CPUs doesn't exist and it's officially not supported, so I tried myself and I succeeded.
-
It's an Unraid share on a local NAS, and the array is formatted as xfs.
Hmm, shared how? NFS?
-
Again, you don't need a VPN if you follow my guide. Your reading comprehension is worse than mine, and I have ADHD. *sigh*
I’m not asking how to do it without a VPN, I’m asking how to do it WITH a VPN.
Not sure what’s hard to understand.
-
I’m not asking how to do it without a VPN, I’m asking how to do it WITH a VPN.
Not sure what’s hard to understand.
And I'm telling you that you don't have to if you use a Debrid service.
But if you insist: all you gotta do set it up on the DNS level. Find out the IP needed to connect to your VPN via DNS, then change your TV's DNS servers to that IP in its internet connection settings.
-
And I'm telling you that you don't have to if you use a Debrid service.
But if you insist: all you gotta do set it up on the DNS level. Find out the IP needed to connect to your VPN via DNS, then change your TV's DNS servers to that IP in its internet connection settings.
“…all you gotta do set it up on the DNS level. Find out the IP needed to connect to your VPN via DNS, then change your TV's DNS servers to that IP in its internet connection settings.”
To anyone reading this, this is not how a VPN works. A VPN (generally) requires a piece of software that gets installed on a client device and securely connects your device to a VPN server. Just pointing DNS entries to the IP address you use to connect to a VPN won’t actually connect you to the VPN.
If that worked, why would the major VPN providers have software based clients?
-
“…all you gotta do set it up on the DNS level. Find out the IP needed to connect to your VPN via DNS, then change your TV's DNS servers to that IP in its internet connection settings.”
To anyone reading this, this is not how a VPN works. A VPN (generally) requires a piece of software that gets installed on a client device and securely connects your device to a VPN server. Just pointing DNS entries to the IP address you use to connect to a VPN won’t actually connect you to the VPN.
If that worked, why would the major VPN providers have software based clients?
I know but what you specifically want is not possible. But yet again it doesn't matter because you don't need a VPN when you use a Debrid service.
At this point you're just harassing me to be a pendantic asshole. So I'm going to do what's best for my mental health and dip out of this conversation. You are exhausting.
️ -
https://github.com/SynoCommunity/spksrc/issues/5941 ?
I really wanted Jellyfin working in my DS214Play with DSM6, and I noticed that a package for these evansport CPUs doesn't exist and it's officially not supported, so I tried myself and I succeeded.
Thanks for the link. It seems they got it somehow working on DSM6, but if I check the thread, it's a lot of ducttape and locktight involved especially to run with DSM7.
Might try it out on a rainy sunday -
Hmm, shared how? NFS?
I'm actually not 100% sure how to answer that. It's just a "share" configured through the Unraid UI, being accessed by a docker container running on the same machine (binhex's Jellyfin image.) I think that the "share" in this context is essentially just a mount point, but it's also (optionally) exposed as an SMB share externally.
-
I can't speak for OP, but I self host lots of stuff, have literally dozens of services running, have an Ansible repo to manage it all and routi some stuff through a VPS, not to mention my day job has included managing services in one way or another for a long while. This is to say, I know what I'm doing. I couldn't setup Plex to work the way I wanted to, they expect it to run in a docker with network set to host mode, I couldn't find any way to tell Plex that my living room TV was in the same network, it just wouldn't accept any connections as local. I know I shot myself in the foot here by not letting it run with network on host mode, but I shouldn't have to, the port was exposed, I could reach it through the local network IP, but I wasn't able to stream any content locally.
If you don't set it to host, the docker container is in a different ip range than your tv. That's why it assumes it's not in the same network (which it isn't)
-
what features are you missing?
security
-
Thanks.
One of my pet peeves is when people immediately jump to whatever their fanboy program of choice is regardless of if it’s actually the right program to run in the situation given.
It's also always the Jellyfin fans that get emotional about this. Liking Plex is like a cardinal sin to them and I should be happy to migrate my entire viewership to a new solutions that requires them to install a vpn client on their device.
Every post I see here about Plex is some variation of Gotcha! or Schadenfreude where they expect everyone to say, "oh no, guess I'll pack it up and start fresh"
-
Natively, you can't. Hackishly, you could put a small VPN capable router in front of it that would manage the connection.
That's according to Dr Internet, so I haven't tried it, but it seems very likely to be accurate.
So instead of a service that works, I now have:
- an inferior (and incomplete) client experience, unless I spend money
- an additional device to allow the client to connect to Jellyfin, because I can't safely expose it to the internet
- the responsibility to keep all that additional stuff working for myself and everyone of my friends/family members
sounds like a great deal
-
The condescension in your first point is brutal. I suggest you apologize.
And I would suggest learning how to configure your software before coming here and stirring shit. But we can't always get what we want
-
Cool, so you can finally admit you set Plex up wrong. Good job.
But somehow it's still Plex's fault
