Plex has paywalled my server!
-
Yeah the link I posted does everything via docker and explains what should be mounted and how.
That's awesome and thank you for sharing that
-
Obscuring home IP is the big one. You also don't have to fiddle with opening ports on your router and maybe getting ISP attention for hosting on a residential network. But really obscuring home IP address would work.
Dirt simplest solution is caddy on the same jellyfin server and port forward 443 and 80 on your router to that host. Hopefully letsencrypt will work without a domain but I'm not sure.
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).
-
For software I like made by people getting paid, I was happy to pay the one time fee. It's really good, secure, and downloads are fast now.
Ditto. There is a crowd on Lemmy who seem to get angry whenever people are happy to pay for software and I do not understand it. Surely we want developers to be paid for their hard work? Don't we want them to able to comfortably live?
-
Welp, i killed mine yesterday as it wouldnt let me stream while offline. Modem died so no Internet for me. Why do i have everything local if it dosent work while offline...
FYI you can definitely watch while your network is offline. You just net to tell it that you're happy with that (it's not activated by default for security reasons).
-
In your Plex server settings, go to Network, enable "Show Advanced".
-
Near the bottom, find the textbox that says
List of IP addresses and networks that are allowed without auth -
In this field, enter the local IP address of any Plex client(s) you want to keep using if your internet (or the Plex cloud) is down.
-
A example:
192.168.0.50 -
Save the setting, done.
#Important thing to be aware of:
What this setting does is tell your local Plex server to simply give any Plex client that connects from that specific IP full admin access to your Plex server, ignoring any account restrictions. This means that if you have things in place to restrict access to some libraries (kids blocked from 18+ movies etc) those restrictions will have no effect. Also if you have the option set to allow file deletion, then any client from that IP could also delete items. And they could of course change any settings in your Plex server. So your kids can watch anything on your server, if you have a guest in your network and they browse to the Plex web interface, they can mess with things.
Because of that I would recommend to limit the amount of IP's you enter in that field to the absolute bare minimum. For example, only whitelist the "main living room device" plus one device you to admin the server, such as a laptop.
If you want to whitelist multiple devices, this is a example:
192.168.0.50,192.168.0.77,192.168.0.80If you want to whitelist a entire network, these would be examples:
192.168.0.0/24 (this means 192.168.0.0 - 192.168.0.255) 192.168.0.0/16 (this means 192.168.0.0 - 192.168.255.255)And of course those involved network devices should use static IPs in your home network.
-
-
Plex server isn't open source.
They’re talking about the Jellyfin crew.
-
Ditto. There is a crowd on Lemmy who seem to get angry whenever people are happy to pay for software and I do not understand it. Surely we want developers to be paid for their hard work? Don't we want them to able to comfortably live?
Agreed. I've stated it before in other threads, and I'll say it again here, but if they asked me in 5 years to pay another $89 or whatever in continuing support for a badge on my server I'd happily do it. Plex is really good. Great UI, great apps, great external enrichments like trailers/subtitles/ratings/actor info, and Plexamp is 9.5/10 for music.
Their biggest fault is how they communicated about the change for remote users. I did have a few family members get the email and ask if they were going to have to start paying monthly now, but they've never been on a free server. They should have stated more clearly than if you were on a Plex Pass server that no change is required.
-
As was stated on the first post you made about this, it's a dns or nat reflection issue.
Plex sees you accessing it through your external IP address, and not through your lan IP.
I had a similar problem, and had to roll back some nat changes I made, and now it's working fine again.
Meanwhile, free remote streaming works fine if you have a proper VPN setup. I just tested it, and was able to stream to my phone, through the Plex app, over my tailscale VPN, and I do not have Plex pass on the server or on my phone...
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..
-
[email protected] wrote:
Great; how do I get my Mother to do that over the phone?
That’s not going to scale as I share out my server.
Are you incapable of recognizing that in this context my comment was a joke? What the fuck is wrong with you?
How are you complaining of someone not recognising a joke when you failed to recognise that the response was a joke, as well?
-
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.
