I think it’s just a matter of getting used to it. I had the same issue at first and the more I used the command line, the more I started to prefer it to GUI apps for certain tasks.

A couple things that I use all the time:

• tab completion is incredible
• cd - goes back to the last directory you were in (useful for bouncing back and forth between locations)
• !$ means the last argument. So if you ls ~/Downloads and then decide you want to go there, you can cd !$.
• :h removes the last piece of a path. So I can do vim /etc/network/interfaces and then cd !$:h will take me to /etc/network.

You ever see those Wired videos where they talk about a concept on five different levels ranging from beginner to expert?

The first level answer is likely that, yes, you’re reasonably secure in your current setup. That’s true, but it’s also really simplified and it skips a lot of important considerations. (For example, “secure against what?”) One of the first big realizations that hit me after I’d been running servers for a little while and trying to chase security is the idea of a threat model. What protects me from a script kiddie trying to break into one of my web servers won’t do much for me against a phishing attack.

The more you do this, though, the more I think you’ll realize that security is more of a process than an actual state you can attain.

I think it sounds like you’re doing a good job moving cautiously and picking up things at each step. If the next step is remote access, you’ve got a pretty good situation for a mesh VPN like Tailscale or Netbird or ZeroTier. They’ll help you deal with the CGNAT and each one gives you a decent growth path where you can start out with a free tier and if you need it in the future, either buy into the product or self host it.

Sorry to say I’ve never heard of spaceship, but wanted to make sure you know that Cloudflare now has a registrar service, so if you’re already using them for DNS, that might be worth a look for you.

Who says you can only get one? Don’t let the perfect be the enemy of the good; just get one of the fun ones you already came up with and in the future if you need a different one get that too. That’s been my approach, anyway.

It sounds like in your situation, you’d create a shared folder where your media lives (smb or nfs) on the Synology and mount that share to the machine running jellyfin. Then adding the folder as a library will be the same as choosing a local folder.

I just had to do this. Don’t skip the release notes. They’re really good at highlighting potential pitfalls, just scroll back through and look for the heading “Breaking Changes.”

In my case there were a few, but they were only for API calls I’m not using, so I just did the update in one go and it worked out great. (Of course, I made sure to take a backup first.)

The two pieces of software have very different topologies.

In very broad strokes: Something like FunkWhale uses a server-client model. To get to it, you connect to it remotely and you need some way to get there. By contrast Syncthing behaves as a mesh of nodes. Each node connects directly to the other nodes and the syncthing project folks host relays that help introduce the nodes to one another and penetrate NAT.

No, you may not need a paid domain to use your self-hosted FunkWhale server (I haven’t dabbled with that service in particular). There are a few options.

1. You could probably use the direct public IP address or alternatively
2. Use a dynamic DNS provider (like afraid.org) to resolve your IP address
3. Use a VPN on all of your clients and use local DNS to resolve your FunkWhale server’s local IP address.

These all assume that you have a public IP address on your router and not one that’s being NAT-ed by your ISP.

Again, these are very broad strokes, but hopefully it helps point your in a direction for some research.

I’m a huge Debian fan, but I’d say everyone should give openSUSE a shot. It’s a well thought out distro that doesn’t get enough love.

Check out ersatztv.org. That software lefts you create custom, continuously playing channels that you can watch from Jellyfin as a live TV channel.

My only experience with homebrew is on macOS and I’ve switched to MacPorts there. Homebrew did some weird permissions things I didn’t care for (chowned all of /usr/local to $USER, if I’m remembering right). It worked fine on a single user system, but seemed like a bad philosophy to me. This was years ago and I don’t know how it behaves on Linux.

I also prefer Firefox, but when I need a Chromium alternative for testing, I opt for the flatpak (or the snap) version personally.

It sounds like you’re seeing a few different issues here and it makes me wonder if there’s some hardware issue that’s causing some of this or if the installation is botched (though it’s be odd for that to hose two different distros.

Last time I looked Debian didn’t include sudo by default, so you’d have to install it first. To add yourself to the sudoers group, log in as root and run usermod -aG sudo mariah (assuming that’s your username). Then reboot (logging out your user should work too, but better be thorough).

Grub sometimes includes a timeout longer than I like and you can edit that in the /etc/default/grub file to something of your liking.

Not sure what you mean about the commands, but maybe it’s an issue with your $PATH.

I second mailcow. It’s what I’ve been using for years and it’s pretty great.

One thing I’ll add is before you take the plunge, make sure your VPS address isn’t on a block list somewhere. Pay a visit to mxtoolbox.com and you should find some resources there.

How about option 3: let Proxmox manage the storage and don’t set up anything that requires drive pass through.

TrueNAS and OMV are great, and I went that same VM NAS route when I first started setting things up many years ago. It’s totally robust and doable, but it also is a pretty inefficient way to use storage.

Here’s how I’d do it in this situation: make your zpools in Proxmox, create a dataset for stuff that you’ll use for VMs and stuff you’ll use for file sharing and then make an LXC container that runs Cockpit with 45Drives’ file sharing plugin. Bind mount the filesharing dataset you made and then you have the best of both worlds—incredibly flexible storage and a great UI for managing samba shares.

For learners who are helped by seeing someone think through a problem and explain why they made the choices they did it doesn’t get much better than YSAP. (Here’s the link: ysap.sh)

I don’t think there’s a right answer for most of these, but here are my thoughts.

Data: I almost always prefer bind mounts. I find them easier to manage for data that I’ll need to deal with (e.g. with backups). Docker volumes make a lot of sense to me when you start dealing with multiple nodes and central management, where you want to move containers between nodes (like a swarm).

Cache: streaming video isn’t super latency sensitive, so I can’t think of a need for this type of caching. With multiple users hitting the web interface all the time it might help, but I think I’d do that caching in my reverse proxy instead.

User: I don’t use the *arr stack, but I’d imagine that suite of applications and Jellyfin all need to handle the same files, so I’d be inclined to use the same user (or at least group) on all of them.

DLNA: this is a feature I don’t make much use of, but it allows for Jellyfin to serve media to devices that don’t run a Jellyfin client. It’s an open standard for media sharing among local devices. I don’t think I would jump through any hoops for it unless you have a use, but the default setup won’t get in your way.

Hope that helps a little.

That fruit argument is so that samba plays nicely with Apple’s SMB client implementation.

Another idea for you: if you use ZFS for the install, check Debian directions on OpenZFS or zfsbootmenu and you’ll get directions for an encrypted installation. You’ll be able to specify the path to a key file, which you can keep on a thumb drive. When the machine boots up, it’ll see the thumb drive and decrypt the zpool automatically; yank the thumb drive and it won’t (backup the key of course).

That metadata is written into the photo by the camera, so Immich may not be able to accommodate this easily. Not sure about Canon specifically, but my Nikon cameras have a memory bank for manual focus lenses. Might be worth checking through your menus.

In general, I prefer unprivileged LXC to a full VM unless there’s some specific requirement that countermands that preference (like running an appliance or a non-Linux OS).

What I tend to do is create a new container for each service (unless there’s a related stack). If the service runs on Docker, I’ll install that right inside the container and manage it with docker compose. By installing Docker directly from get.docker.com instead of the built in packages, it pretty much works all the time.

Since each service is in its own container, restoring backups is pretty service-specific. If you wanted some kind of central control plane for docker, you could check out swarm mode.

It’s not exactly a single tool, but torsocks kind of enables doing what you’re describing. The syntax would be something like torsocks curl $url