

Can’t say I disagree.
🇨🇦
Can’t say I disagree.
Yeah; Emby was originally called MediaBrowser and was a free open source project. ‘MediaBrowsers’ developers decided to move to a closed source paid model to establish some more consistent income and support the dedicated developers they have. Thus Emby was born.
Some users were really unhappy with this decision and forked MediaBrowsers last release to create Jellyfin. Their development has been quite a bit slower, but they’ve made some significant strides in recent years. It’s a more and more attractive option.
One of my biggest reasons for sticking with Emby (besides already having a lifetime premier license) is the dedicated clients available on more platforms. Xbone is my primary streaming device, besides android: Emby has a dedicated xbox client you can install that will take full advantage of the the hardware(more content direct plays, HEVC video for example), where as Jellyfin you’ve gotta use the web browser which is cumbersome and forces the server to transcode media a lot more.
In the case of plex, it’s not 100% selfhosted. There’s a dependence on plexs public infrastructure for user management/authentication. They also help bypass NAT by proxying connections through their servers so you don’t have to setup port forwarding and can even easily escape double NAT situations.
I can understand paying for that convenience, but cost keeps rising while previously free features continue to get locked behind paywalls.
Tbh, having users required to authenticate with plex.tv was enough for me to look elsewhere. The biggest reason to self host for me is to remove dependency on public services.
I got the same email.
I haven’t had plex installed for over 7 years, and I’ve NEVER used the shared libraries feature.
We noticed that you’ve accessed libraries from friends and family in the past
They’ve apparently noticed activity that’s never occurred.
You could setup a user account like the share you’re describing. There’s a setting to prevent the user from changing their password.
Just pass out those credentials to anyone you want to collaborate with; they don’t need their own individual accounts.
I’ll try the unsubscribe link, if that fails I’ll directly email addresses like [email protected], info@, support@, service@, hr@, admin@, abuse@ requesting I be removed from their mailing lists.
If all those fail (I’m still getting spam later), I whois lookup the domain and send a complaint to the listed abuse address for the registrar. That typically goes through AWS who follows up asking for the email source headers to investigate.
It usually ends there.
I use https://filebrowser.org/ for this.
Nice lightweight filebrowsing/sharing with user management. Users can have their own dedicated directories, or collaborate.
You can also create share links that allow anyone with the link to view/download files. Optionally password protected.
Here’s a demo you can mess with: https://demo.filebrowser.org/ User: demo Pass: demo
Most of my web services are behind my vpn, but there are a couple I expose publicly for friends/family to use. Things like emby, ombi, and some generic file sharing with file browser.
One of these has a long custom path setup in nginx which, instead of proxying to the named service, will ask for http basic auth credentials. Use the correct host+path, then provide the correct user+pass, and you’ll be served an openvpn configuration file which includes an encrypted private key. Decrypt that and you’ve got backdoor vpn access.
I keep vaultwarden behind a vpn so it’s not exposed directly to the net. You don’t need a constant connection to the server; that’s only needed to add/change vault items.
This does require some planning though; it’s easy to lock yourself out of your accounts when you’re away, if you don’t incorporate a backdoor of some kind to let yourself in in an emergency. (lost your device while away from home for example)
My normal vpn connection requires a private key and a password that’s stored in my vault to decrypt it. I’ve setup a method for retrieving a backup set of keys using a series of usernames, emails, passwords, and undocumented paths (these are the only passwords I actually memorize); allowing me to reach vaultwarden where I can retrieve my vault with the data needed to login to everything else properly.
Usually that does the trick for me too; but this morning it just would not cooperate no matter what I tried.
Seems to be playing ball again, for now.
I have a feeling this is more to do with Android/Google not wanting to give up control more than anything. If googles stuff always works, but third party stuff is mysteriously always glitchy; users are going to gravitate to google and their ever growing monopoly…
Thank you! You gave me the hint I needed.
I didn’t know there was a quick setting button (the buttons in the notification tray) and have been struggling to find the accessibility options people have mentioned.
That button in the tray seems so much more reliable. Thanks again!
I tried. I couldn’t get it to work again, so wanted to look at other options alongside looking for help/solutions.
But just as it decided to stop working, despite my efforts; it’s suddenly started working again.
Sigh…
Vaultwarden is just a self-hosted server for Bitwardens clients. It’s Bitwardens android client I’ve been having issues with.
That’s an interesting option. It’s the Bitwarden app I’ve been having issues with; though I’m not sure how much of that is Bitwardens fault vs Android itself.
I’ll give that a look, thanks :)
I’m so tired of seeing this overblown reaction to ancient non-news.
Yes, there are some minor vulnerabilities in Jellyfin; but they really really aren’t concerning.
Unauthenticated, a random person could potentially (with some prior knowledge of this specific issue, and some significant effort randomly generating media UUIDS to tryout) retrieve/playback some media unauthorized. THATS IT. That’s the ONLY real concern. And it’s one you could mitigate with a fail2ban filter if you were that worried about it.
The other ‘issues’ here, are the potential for your already authenticated users to attack each others settings. Who do you share your server with that you’re concerned about them attacking each other???
Put this to bed and stop fussing over it. It’s genuinely not worth your time or attention. Exposing Jellyfin to the net is fine.
Dev comment on the situation: (4 days ago) https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2825240290
Where in the world did you get that idea?
VPNs serve three functions:
add a layer of encryption so your local network operator and ISP can’t inspect your traffic, its contents and its true destination. (this is what OP is looking for)
make it appear to the service you are connecting to, that you are connecting from a different location than where you actually are. (for example make Netflix think you’re in a different region to show you different content)
provide secure access to private services that are not exposed directly to the Internet. IE securely connecting devices on seprate LAN networks together over the Internet via an encrypted tunnel. This is a VPNs true purpose and how they are primarily used in Professional/Comercial settings. (pretty much every corporation you’ve ever interacted with runs a VPN that connects its stores/warehouses/offices together)
I really don’t like the idea of every device automatically having a publicly reachable IP.
There’s certainly situations where that would be nice; but I’m quite fond of most equipment and services being behind a router and it’s firewall, requiring explicit configuration to be exposed to the open net.
Nobody outside my home network ever needs access to my toaster… (btw, why tf is my toaster wifi enabled…?)
My ISP blocks the ports needed for mail hosting :/
Pretty sure I’d have to go through them to get the rdns PTR records pointed at my domain too. PITA
Actually it looks like Caddy is supposed to set those automatically (I’m used to Nginx which doesn’t).
You’ll have to look at why the upstream isn’t accepting them then. I’m not familiar with azuracast.
Without authentication; it’s possible to randomly generate UUIDs and use them to retrieve media from a jellyfin server. That’s about the only actually concerning issue on that list, and it’s incredibly minor IMO.
With authentication, users (ie, the people you have trusted to access your server) can potentially attack each other, by changing each others settings and viewing each other’s watch history/favorites/etc.
That’s it. These issues aren’t even worth talking about for 99.9% of jellyfin users.
Should they be fixed? Sure, eventually. But these issues aren’t cause to yell about how insecure jellyfin is in every single conversation, and to go trying to scare everyone off of hosting it publicly. Stop spreading FUD.