-
Torrent Downloads Failing when Downloading to Cache as Primary Storage
And nevermind, the issue is back again, no changes made.
-
Torrent Downloads Failing when Downloading to Cache as Primary Storage
I didn't edit any of those settings when I did this recent change, I cannot remember if I adjusted it sometime in the past few years though. That said, after updating to the full 7.2 release the cache appears to be working, knock on wood.
-
Torrent Downloads Failing when Downloading to Cache as Primary Storage
I would agree if not for the fact that it was working fine a few days ago and started acting up without any changes being made that I can think of. I upgraded to the latest RC update a few days before this issue started. A few weeks ago I redid my storage to match the TRaSH guides for automating everything and it was working great, in the multiple years I have ran Unraid I have never encountered this issue before. My torrent client of choice is binhex-qbittorrentvpn but I tried Transmission and Deluge with the same result. I have attached two diagnostics, one with the cache enabled as primary storage and array secondary, and one with only the array as the primary storage. As soon as I switched the share to array only I hit resume on a torrent for a Fedora Linux Silverblue ISO and the download worked instantly as an example. ARRAY ONLY-unraid-diagnostics-20251027-0002.zipWITH CACHE-unraid-diagnostics-20251026-2358.zip
-
Torrent Downloads Failing when Downloading to Cache as Primary Storage
As the title states, torrent downloads are failing when I have the cache set as primary storage, but when I have the array as primary storage it is working fine. All drives pass SMART tests and the cache drive is almost entirely empty. I have tried multiple docker torrent containers and it is not limited to just my primary client or to one docker author.
-
-
[Solved] Can't make NFS shares to work, Am I missing something?
Try using this as your command, SMB has a slightly different path than NFS mount.exe -o anon nolock "\\[HOST ADDRESS]\mnt\user\[SHARE NAME]" [DRIVE LETTER]:
-
Figro's Docker Repo Support Thread
I have been getting similar errors from yarn too on Flood-UI flood.log
-
[Support] binhex - UrBackup
I see that we should be able to mount VHDZ images to the PC using the WebGUI on the project page, however that option is not available. Is that a limitation of running UrBackup in this Docker container or is it just unmet dependencies?
-
[Support] binhex - Plex Pass
I had the same issue, I couldn't find a solution so I had to switch to the 'linuxserver' version of Plex instead as it uses a different method of claiming a server
-
[Support] binhex - Plex Pass
Is it possible for you to add the server claim variable to the template like the linuxserver version? I had to reinstall cause my Preferences.xml got corrupted and I couldn't fix it by deleting, then no matter what I did while reinstalling I could not claim the server, it never gave me the option. Yes I cleared the template and cleared the appdata for the docker container first too.
-
eth0 not found after upgrade to 6.10.2
Either way, still needs to happen rather than having to check a forum post. You should feel safe when upgrading on the stable path that something like this wouldn't happen
-
eth0 not found after upgrade to 6.10.2
I had the same issue. I think that with the prompt to upgrade in the dashboard with no warnings about these issues is going to cause a lot of people to go through this. The Dashboard should absolutely provide a warning or show the changelog before you see the upgrade button
meechgalhuquot
Members
-
Joined
-
Last visited