I went with rsync.net, grabbed a promo at some point and have been getting 1.6TB for $10/mo. They support a wide range of protocols (sshfs, sftp, rsync, borg, synology, guides for freenas and truenas), snapshots, idle alerts, geo redundancy for a fee. Been very happy with it so far. Had to retrieve some files once and had no issue.
Doesn’t this need an AI disclosure in the title and post per the rules of this community?
Honestly I like the idea of your project but the writing style of your post is very grating.
Ah cool, the docs made it sound like container: uses the container ID hash instead of the name so I wasn’t sure how that works. I just put stuff like this in the same compose file since they’re all closely related.
If it helps, here’s how I had my gluetun / transmission set up with mullvad (I’ve since moved to proton for port forwarding but I saved the mullvad config in case I needed to switch back):
services:
gluetun:
image: qmcgaw/gluetun:v3
container_name: gluetun
restart: always
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
volumes:
- ./volumes/gluetun:/gluetun
environment:
- TZ=America/New_York
# Mullvad
- VPN_SERVICE_PROVIDER=mullvad
- VPN_TYPE=wireguard
- SERVER_COUNTRIES=USA
- SERVER_CITIES=New York NY
- WIREGUARD_PRIVATE_KEY=
- WIREGUARD_ADDRESSES=x.x.x.x/32
- UPDATER_PERIOD=24h
- UPDATER_MIN_RATIO=0.1
- UPDATER_VPN_SERVICE_PROVIDERS=mullvad,privado,protonvpn
networks:
- default
- ingress
transmission:
image: linuxserver/transmission:latest
container_name: transmission
restart: always
network_mode: "service:gluetun"
environment:
- PUID=0
- PGID=0
- TZ=America/New_York
volumes:
- ./volumes/transmission:/config
- /volume1/Media:/media
flood:
image: jesec/flood:latest
container_name: flood-sidecar
restart: always
command: --port 3000
user: "0:0"
network_mode: "service:gluetun"
volumes:
- ./volumes/transmission:/config
- /volume1/Media:/media:ro
environment:
- TZ=America/New_York
- HOME=/config
labels:
- com.centurylinklabs.watchtower.enable=true
- "traefik.enable=true"
- "traefik.http.routers.flood.rule=Host(`flood.example.com`)"
- "traefik.http.services.flood.loadbalancer.server.port=3000"
- "traefik.http.routers.flood.entrypoints=websecure"
- "traefik.http.routers.flood.tls.certresolver=mytlschallenge"
# This example uses "Selective Authentication"
- "traefik.http.routers.flood.middlewares=oauth-middleware"
Idk how zimaos works, but the way to attach containers like this is with network_mode: "service:othercontainer" which might need them to be in the same compose file (the docs aren’t clear).
Also note that you can’t put any port mappings on a container using network_mode service, you have to put them on the other container that is handling networking since the first container is piggybacking off of the other and doesn’t have its own networking.
It sounds like it’s just not worth it for you, and that’s totally fine! Plenty of people get by just fine with using random streaming sites.
Personally, I want something more reliable, I want to have copies of what I watch in my possession that cannot be taken down, and I want to share this with others so that my friends can benefit from my time investment instead of using a solution that only works for me. So that if my friends ask me “where do you get your stuff” I can offer to share with them at 0 extra effort instead of telling them “go do all these things that I already did”
As for usage, I only watch a few hours a week myself, but I share with 15-20 friends and family who watch a collective 160 hours a month last year and around 360 hours a month this year (about 15 days of watch time per month).
I have a fairly comprehensive arrstack, torrents and Usenet, seerr, Plex and jellyfin side by side with identical media mounts for maximum user choice, running on a nuc with quicksync so it handles 8+ simultaneous 1080p live transcodes without using much power or increasing CPU usage much more than 5-10%.
First thing that springs to my mind is bad adhesion. Have you washed the bed with dishsoap recently? Usually not touching the bed with your fingers is enough but sometimes I need to “reset” by giving it a good wash.
Mmmm fresh slop
They also forgot to change r/selfhosted from when they posted it to reddit… https://www.reddit.com/r/selfhosted/comments/1ter9n9/refearnapp_opensource_selfhosted_affiliate/
As well as: https://www.reddit.com/r/selfhosted/comments/1sk4oqw/refearnapp_selfhosted_opensource_affiliate/
Here’s their answers to “Expand the replies to this comment to learn how AI was used in this post/project”:
it is written by ai i give the idea then ai writes that
this post is written by ai. i only give it thought on what idea it should post and it generated everything.
Their post history contains a mixture of comments with grammar like the above as well as many comments with excellent grammar, often containing em dashes. It seems like they only post on Reddit using AI comments to karma farm so they can spam AI generated posts like this to try to get some people to pay for their hosting subscription for their vibe coded app.
I think you should make it clearer in this post that you are selling hosting services for this. It feels like this is self promotion but without transparency otherwise.
Idk about giving a comprehensive answer, but getting full marks on the nextcloud security scanner is a good start: https://scan.nextcloud.com/
I check mine periodically and make sure I’m on the latest version, use 2fa (passkey) and hope that does the trick.
Also there’s a plugin for brute force protection.
That’s exactly the point I’m getting at. Putting an auth wall doesn’t work with many apps, and if you add exceptions to the API then you’re not really protecting anything.
What do you mean viable? The web UI is just an app that is delivered to your browser, it makes more or less the same API requests as an app would make, so IDK why the risk would be lower with an app?
If an attacker can access the login endpoint for example to brute force or dictionary attack, it doesn’t matter if the web UI is or isn’t accessible if the login endpoint it uses is exposed for an app. The attacker could serve their own copy of the web UI and proxy requests to the API your app connects to. Blocking the html from being served doesn’t make a difference.
Gotcha I see, just checking if I missed something since that was the issue last time I tried doing something like that. These days I just yolo it and expose jellyfin to the public Internet.
How do you get apps through something like that? Do you have to open your browser and hit the URL periodically to handle auth there and it just remembers your IP?
For starters, it being brought up wouldn’t be an issue if there was some timeline to fix it and the response wasn’t just “it’s too hard and would break clients”, and secondly, I think it’s not congruent with wanting to improve jellyfin if your reflex is immediately to say that nothing is truly secure. Could you imagine if next cloud had a similar issue and put it off for more than 5(?) years?? Is that really not enough time to get the clients and apps in order? They should just put the issue to rest so we can move on with making jellyfin better. I don’t think anyone wants it to remain an issue for another 5 years, and I think calling that blown out of proportion is kinda ridiculous.
Like if 5 years ago they said you have 5 years to update your app, we could have had this issue checked off and nobody would be able to complain about it or use it as an excuse not to switch, so the next best time to set a deadline would be now. They should just as soon as possible say you have a couple years to update your apps, at least schedule a date years in the future to rip off the bandaid instead of kicking it further down the road.
Sure not knowing of an issue doesn’t mean it’s secure, but that doesn’t also mean that projects with known issues aren’t a problem… Like if you want jellyfin to be popular you should want this to be fixed - I don’t get this attitude from people who main jellyfin who seem opposed to pushing for it to be better. It not being a big issue is your own personal opinion - it’s obvious that known security issues sitting around for a long time bothers a lot of people so the sooner it gets addressed, the fewer reasons people have to stick with Plex. That’s a good thing right?
Ok, well you just made it sound like the main issue was the lack of audit /guarantee and not an actual security issue. I don’t think breaking clients is an excuse not to at least get started putting forward a date, even if it’s a year in the future, where clients need to be updated by. Sure Overseeer isn’t begging people to put it on the internet, but there aren’t any known vulnerabilities to my knowledge, same with vaultwarden. Imo it’s a big win to getting more people comfortable using jellyfin if they can put their foot down and say clients need to update, or stay on the old version. Every time there’s Plex drama, it seems like the list of reasons people don’t want to spend time to migrate isn’t getting whittled down much. I’ve donated hundreds of dollars over the years at this point to jellyfin proper as well as several clients hoping things could move faster. Like imagine if the Overseeer devs designed a frontend. There’s nothing that jellyfin can’t technically do that I find missing, but it feels like a death by a thousand cuts.
How come this is not an issue for other projects then? Why isn’t Overseer also saying "don’t host this publicly because we can’t also can’t guarantee perfect security? Is the issue really just that they can’t prove security or is there an actual security issue with the API? From what you’re saying it sounds like the only issue is that they haven’t done an audit but that it’s otherwise fine, but other people are saying there are actual security holes regardless of whether an audit is performed.
Like, I’m fine running stuff publicly that hasn’t been audited like most of the stuff I self host. Why are people treating jellyfin differently than other self hosted projects that haven’t been audited?
I have about 50% humidity and don’t usually dry my filament and I start to have issues with the outer layer of the spool snapping repeatedly when feeding after a year or two of sitting out. I used to have a dryer for cases like this but it got left behind in a move so I currently try to only use my new spools until I can get another one because I don’t trust using the oven and using the heat bed is really slow.