Plex has paywalled my server!
-
This sounds like a whole lot of convoluted bullshit to use Plex locally and "looking local" through VPN solutions when you could just roll a Jellyfin instance and do things a more straightforward way..
Yeah, but my wife and kid also use it, and they're not going to be happy if I change things.
-
How is your underlying file system set up?
wrote last edited by [email protected]It's an Unraid share on a local NAS, and the array is formatted as xfs.
-
Plex has pay walled FREE servers streaming to FREE clients only.
If you have a plex watch pass (for client) you're good and can stream from any server. If you have a plex pass (for server) any one can stream from your server. But you have to have one or the other.
Yes. But it used to be free to watch remotely. It's 99% your own hardware doing everything. Their services get used for discovery, not as proxies for the connection itself, AFAIK.
You already had to pay them to allow transcoding with your own GPU, etc.
Right now it's still not too bad, but just watch, enshittification will affect paid users too. For one, I expect the lifetime pass to go away, and go away retroactively eventually.
-
The way people act while advocating for something does in fact affect the efficacy of their advocacy whether they want to admit it or not.
wrote last edited by [email protected]I'm sure that's correct. Richard Stallman would be a good example of that, sadly. I doubt anything as negative has been said in this thread, or site. Seems more like people feel attacked when free software advocates point out uncomfortable issues. Like how people get annoyed with vegans talking about animal cruelty (I eat meat, saying that to avoid theonejoke).
-
Old news, but time for Jellyfin. I made the switch a couple months ago. Some minor teething issues, but better, IMO, especially now as my family all have LDAP users and that just works.
Give me a package that runs on my ds214play and I'll switch in a heartbeat
-
I'm sure that's correct. Richard Stallman would be a good example of that, sadly. I doubt anything as negative has been said in this thread, or site. Seems more like people feel attacked when free software advocates point out uncomfortable issues. Like how people get annoyed with vegans talking about animal cruelty (I eat meat, saying that to avoid theonejoke).
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.
-
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.
