After the last update to TrueNAS-13.0-U6.2 I noticed that I can no longer get to the Management page of the qBittorent plugin. When accessing the Shell of the plugin and trying to restart it using this command service qbittorrent restart I ended up withe the following error:
qbittorrent not running?
Starting qbittorrent.
ld-elf.so.1: /usr/local/lib/qt6/libQt6Xml.so.6: Undefined symbol “_ZTVNSt3__13pmr25monotonic_buffer_resourceE”
/usr/local/etc/rc.d/qbittorrent: WARNING: failed to start qbittorrent
Can anyone assist with this. I know a move to SCALE is long overdue, but I don’t really have the time to do the move now.
How “painful” would be the move regarding to keeping the DATA? I have 4 drives in 2 Raid 0 configs that I share via SMB and some simple jails: PLEX, qBittorent and Transmission.
You have two vdevs, both of which are non-redundant stripes? Can you double check this?
The two sets of data that matter in regards to qBittorrent are (1) the shared/downloaded files themselves and (2) the application’s config/cache.
The location of the shared/downloaded files are ideally located in a dataset of your storage pool. The pool can be imported into SCALE like any other ZFS pool. (Just make sure you’ve been using “mountponts” in your qBittorrent jail this entire time, rather than saving the downloads directly in the jail’s internal filesystem.)
The location of qBittorrent’s config/cache is located within the jail’s internal filesystem under the directory /var/db/qbittorrent. This entire directory can be backed up and transferred via cp, rsync, or tar. (You’ll have to make sure it uses the correct ownership in SCALE, since the UIDs might differ between Core and SCALE.)
Something like this. It looks like I confused the Raid Level. It’s a Raid 1 - 2 pairs of disks containing the same data for redundancy (albeit very limited but I always keep a cold spare just in case).
I am not THAT worried about the configuration of the qBittorent, I can manually restore that, and yes, the data is stored in a dataset that was mounted via a mountpoint. What I am worried about is the actual data and the fact that the jails were run on ONE of those pool while the actual TrueNAS was on a separate SLC SSD of about 32GB.
I take it to mean that you have two pools, and each pool is comprised of a 2-way mirror vdev.
Keep in mind that the directory (in my previous post) doesn’t only contain the “config” and “settings”, but also the statistics. (In case you might want to preserve such stats for posterity.)
Technically, you can just point the “App” in SCALE to that directory as your download location.
That has no effect on the downloaded data itself (as long as you didn’t do anything fancy with symlinks or try to create a convoluted setup.)
Case in point: You could take your disks, plug them into a different system, boot up a Linux live ISO, import the pools with ZFS, and you’ll have access to all your datasets, folders, and files; including your downloaded torrents.
What I was planning to do first was to get another SLC SSD, install SCALE on there, import the configuration from CORE into it and only afterwards connect the actual Disks to the system. Are there any “underwater stones” I might encounter with such an approach?
The config file has information about the disks and pools. You’ll likely end up with a red error symbol in the dashboard about the “missing” disks that are expected to be present for the pools.
Well I wish I was able to access my current instalation if possible - I have several RSS Feed links there I’d like to copy. I will consider using qbittorent-nox, but also planning on switching to TrueNAS Scale at some point.
