There are two kinds of self-hosters: those who backup, and those who will start testing em after their first failed restore.

Congrats on becoming one of the 5% of ppl who backup, but actually also test them.

• I personally wouldn’t be touching /etc/crontab, but adding or editing a tab in /var/cron/tabs.
• I would use _test or just a bash eval instead of mkdir to check for the existence of a directory. Mkdir has backfired on me spectacularly in bash and sh scripts.
• always grep, then sort, then awk. Just as a habit, any other order can make run time long and cause globbing problems.
• good job

Your said you were going to use the cloud services, so even if you self-host, using a cloud service api carries the same risk as using their apps. This is an app to unify all the remote storage things.

However, after looking at the code, I retract my comment and caution you not to use Drivebase:

[crypto]
# Generate: openssl rand -base64 32
masterKeyBase64 = "<base64-encoded-32-byte-key>"

If this is a salt or a seed, the documentation is wrong. But it looks like they’re using this base64 value as the actual key for whatever encryption Claude has vibe-coded into it.

base64 values can be reversed very trivially.

Don’t use this.

Regarding the access to cloud, it’s been done with fuse many times and it is very useful for those who need it.

You should know that many of these cloud services claim they “don’t know what’s in your files”, but have been shown to absolutely be able to access them on request from court order or law enforcement. Just saying.

The path to uptime is paved with understanding what broke and when.

Ipv4 TLD exhaustion happened in 2011, but it was functionally impossible to get a public IP directly from IANA closer to 2005.

And the routing would be a nightmare because if you have multiple gateways between non-overlapping CIDR ranges, you need to tell routing equipment how the packet should return to its source.

So ignoring there being no reason to expose sonarr or radarr to the public at large in the first place, you would be working with two potential scenarios with multiple IPS: either you have two distinct subnets blocks behind your gateways, or you you have two gateways to a single subnet.

In the first case, you would have to route traffic between the two subnets, which makes the scenario not make sense, because why would you need packets between two local hosts to pass through their gateways through public space when they could just be in the same subnet. In the second case, you would have to specify to all your internal hosts two gateways so traffic know which public IP to return to.

Neither of these scenarios make sense when NAT is a much simpler (and cheaper)solution.

I don’t expose much, just an always-on VPN. My HTML only site lives on vps, from which i can cut-and-run anytime. I don’t have much need for more, really.

Back when I was working more with raw infosec stuff like packet analysis, etc, I thought surely we would see machine learning in every router to dynamically manage firewalls in such a way that they became foregone conclusions. We don’t really have that, but code has sure changed, and you’re right, we will see lots more vulns discovered and exploited at a much faster pace.

Workaround to what? Why would radarr need a public-facing presence?

And even if there is a use case, the routing alone would be a nightmare.

I’ve used Incus (but not incusos) for over two years now. Works well.

Stability is great, flexibility to do what I need is also great.

Also there are quite a few options for deployment, I use ansible.

What does that have to do with the PHP vulns?

What do you mean “DNS exploit”? Neither 109618 nor 109619 mention dns in the exploit path…

I have limited exposure to snaps, but from my experience, the oldest eventually gets overwritten by newer ones.

Loop devices are just files mapped as block devices. Snaps cordon off an area on disk for install and config, you should probably see more than one per app if you updated, that’s how snaps can be reverted to previous versions. You can set how many versions snaps keep per app.

I have the jonsbo n1 sitting in a corner, because it is a poorly-designed case with awful ventilation. I don’t know about the other iterations.

No worries, and I’m glad it helped!

I’ll add that I was also mystified by the remote path option for a long time, I think the wiki should show more clearly what this does and maybe an example.

Also, I used to run into issues of running into permissions errors because the download client wrote the files with the wrong permissions. Many nzb and torrent clients have a POSIX masking option that allows you to set the permissions at the time of writing.

1st thing to check is permissions, I have seen radarr/sonarr complain about the path “not existing”, but actually the download client process had no write permission to the destination.

From the radarr wiki:

Generally, a remote path map is only required if your download client is on Linux when *Arr is on Windows or vice versa. A remote path map is also possibly needed if mixing Docker and Native clients or if using a remote server.

Since radarr >4.x, there hasn’t been a need for remote path between Linux machines, not sure about sonarr, but they are similar.

Now for your case, your qbittorrent host does not know about /srv/ in its path, it only knows about /data and everything under it:

qbittorrent:  
    volumes:  
      - /home/marighost/docker/seedbox/gluetunconfig:/gluetun  
      - /home/marighost/docker/seedbox/qbittorrentconfig:/config  
      - /srv/data/torrents:/data/torrents

So when radarr tells

Host: qbittorrent  
Remote Path: /srv/data/torrents/  
Local Path: /data/ 

qbittorrent, which lives inside its docker world, has no idea what /srv means.

Removed by mod

Removed by mod

Ya, it does what it says on the tin. My domain there is nearly 17 years old now.