I’ve not used Symfonium, but I use substreamer on iOS and it’s perfectly serviceable: https://apps.apple.com/us/app/substreamer/id1012991665
tvcvt
There was a recent conversation on the Practical ZFS discourse site about poor disk performance in Proxmox (https://discourse.practicalzfs.com/t/hard-drives-in-zfs-pool-constantly-seeking-every-second/1421/). Not sure if you’re seeing the same thing, but it could be that your VMs are running into the same too-small volblocksize
that PVE uses to make zvols for its Vans under ZFS.
If that’s the case, the solution is pretty easy. In your PVE datacenter view, go to storage and create a new ZFS storage pool. Point it to the same zpool/dataset as the one you’ve already got and set the block size to something like 32k or 64k. Once you’ve done that, move the VM’s disk to that new storage pool.
Like I said, not sure if you’re seeing the same issue, but it’s a simple thing to try.
My go-to for this is a plain Debian or Ubuntu container with Cockpit and the 45Drives file sharing plugin. It’s pretty straightforward and works pretty well.
To amplify RedWeasel’s very good answer, fstab
runs as root and unless you specify otherwise, the share will mount with root as the owner on the local machine. From the perspective of the Samba server, it’s the Jellyfin user accessing the files, but on the local machine, but local permissions come into play as well. That’s why you can get at the files when you connect to the share from Dolphin in your KDE system—it’s your own user that’s mounting the share locally.
You can set maintenance schedules in Uptime Kuma and alerts won’t be sent out during those times. I use that for when my backup routines run each night. That seems like a decent cross-platform work around.
I administer a handful of FreePBX systems that run pretty smoothly and are relatively friendly to use. Crosstalk Solutions on YouTube has a bunch of videos on the software if you want to get up to speed about how everything works.
Not sure how your stack works together, but sudo
will let you run particular commands as a different user and you can be pretty specific with the privileges. For example you can have a script that’s only allowed to run docker compose -f /path/to/compose.yml restart containername
as a user in the docker group. Maybe there’s some docker-specific approach, but this should work with traditional Unix tools and a little scripting.
Cool. That looks right. Have you checked that the bridge is set up properly and that the router doesn’t have anything silly going on for that subnet?
PVE’s network settings are in /etc/network/interfaces
and that’s where you can see how the bridge is set up.
It might be beneficial to know more about your network. Is this the only subnet or do you have a bunch of VLANs? Can other devices on the subnet ping outbound? Have you looked at the firewall on PVE?
This really sounds like a problem with the default route. What’s the output of ip route
? That should give us some hints about what’s up.
Depends on the seller. It’s pretty easy to drop the seller a line and ask for details (and if they’re unwilling to provide them that could be a red flag). I had two drives die during burn-in once. I try to pick reputable sellers and they were pretty quick to replace them.
I see a ton of price fluctuation in used drives. One way I’ve had some success is in seeking out drives sold in lots. Often I’ll also see SAS drives sell for less than a SATA drive of the same size.
If you want an image, it doesn’t matter what the underlying file system is. You should be able to use a tool like Clonezilla and get a 1:1 copy. Depending how you’ve set up partitioning, you could also use
sgdisk
to set up the proper partitions andzfs send/recv
for the new data portion of the drive and install a boot loader. That’s probably the way I’d go in this instance.