deusxanime

Same for me. Just updated my qB docker container a bit earlier today and then I went to grab some torrents where I need to select only certain files and the Content tab is broken! I think it is something with the new version of qB and not just specific to this container or unRAID. Here's a reddit thread where they have the same problem on Proxmox. Also looks like there is a bug on github where they are running on Debian, etc. May need to revert to a previous version for now until it is fixed. edit: Reverted back to this release: "binhex/arch-qbittorrentvpn:5.1.2-2-01-" (I think the last 5.1.2 container binhex put on dockerhub). Confirmed the Content tab works again for me on that version. I'll have to remember to revert back to "latest" tag after the bug is fixed and container updated.

I think restarting the docker container will overwrite the default jar file if it is different from the latest official? So it likely keeps getting overwritten with the official/standard server jar each time your restart. If you are using a non-standard jar file for your server, then set the CUSTOM_JAR_PATH variable in your minecraft container's settings/config (click on the container in the unRAID docker page and select Edit). For me, I use paper for my server jar and have that variable set to "/config/minecraft/paper_latest.jar". It should be set to the path that will be seen from inside the container and by default the appdata is mapped to /config inside the container, so follow that to figure out your appropriate path.

If you have your MC world data in /mnt/user/appdata/<container>/*, then it shouldn't take up space in your docker image. I don't think you need to change anything in server.properties as far as the server jar file, that I remember anyway. You should set the CUSTOM_JAR_PATH (that is what the variable is named in binhex's MC container) of the container to point to whatever server jar you put in there, if not using the default one. To set that, it should be in the list of parameters/variables you are presented when you first install the docker container, or if you already have it installed go to the Docker page, click your container's icon, then select Edit to adjust the variable/parameter. The /mnt/user/appdata/<container>/ is mapped to /config in the container by default, so I have my CUSTOM_JAR_PATH set to /config/minecraft/paper_latest.jar for example. The tag is the same as I just discussed above - CUSTOM_JAR_PATH. If you want to run an older version of vanilla I think the easiest way is to download the specific version's server jar file and put it in your appdata location with a different file name than default and set the custom jar path variable to point to it. That way it won't get overwritten by an auto-update either. And that post is from 2020 that your replied to. Not sure if things have changed since then, but I've been using Paper as my server jar for MC for a long time and it works great. Just download the Paper server jar file, put it in your appdata location, and change the CUSTOM_JAR_PATH to point to it, like the path in my example above.

Uninstalled and reinstalled the TS plugin using the link, and it all looks good now again. I tried upgrading after to see what would happen and got the warning that v6.12.0+ is now required, so that is good as well. Thanks!

v7.0 only came out a couple months ago, and they've only had one bugfix so far to v7.0.1. As someone who has been burned on updates before, I'm not in a rush to go to v7.X until it has had some more burn-in time and/or another round of bug/security fixes. Everything works great right now on my v6.11 and there's no new features I need right away in v7, so mostly just upgrading to v6.12.X for the security fixes for now. So 75% are already on v7.X? Frankly I'm surprised if it already has that take rate! Thanks for supporting us turtles for a little while longer!! Speaking of v7 though, what is the upgrade path for your plugin when I do go there? v7 has Tailscale built-in to the unRAID OS now right? So does the upgrade to v7 detect that I already have the Tailscale plugin on my v6 install and move the config over, do I need to uninstall the TS plugin before upgrading to v7 and manually re-set it up again, or something in-between? Thanks I'll give that a try this evening when I get back home again. Does the config/settings get preserved when uninstalling/downgrading?

Attached the diagnostics. And understood on updating. I'm planning on bringing my server down to do my spring cleaning and dust blowout of it soon (if it ever warms up here!) and I'll be updating to v6.12.X then. yggdrasil-tailscale-diag-20250325-172218.zip

The Tailscale plugin on both my unRAID v6.11.5 servers updated a day or two ago and they are both giving an error now. First off, I pretty much immediately got this email alert from both servers after updating: Fatal error: Uncaught Error: Class 'Tailscale\Utils' not found in /usr/local/emhttp/plugins/tailscale/include/common.php:9 Stack trace: #0 /usr/local/emhttp/plugins/tailscale/pre-startup.php(7): require_once() #1 {main} thrown in /usr/local/emhttp/plugins/tailscale/include/common.php on line 9 And if I go into Settings > Tailscale, I see this: Oops! Something unexpected has occurred, and this page cannot be loaded. Please report the following error on the plugin support thread: Error Object ( [message:protected] => Class 'Tailscale\Utils' not found [string:Error:private] => [code:protected] => 0 [file:protected] => /usr/local/emhttp/plugins/tailscale/include/common.php [line:protected] => 9 [trace:Error:private] => Array ( [0] => Array ( [file] => /usr/local/emhttp/plugins/tailscale/include/Pages/Tailscale.php [line] => 6 [function] => require_once ) [1] => Array ( [file] => /usr/local/emhttp/plugins/tailscale/include/page.php [line] => 31 [args] => Array ( [0] => /usr/local/emhttp/plugins/tailscale/include/Pages/Tailscale.php ) [function] => include ) [2] => Array ( [file] => /usr/local/emhttp/plugins/tailscale/include/page.php [line] => 11 [function] => Tailscale\includePage [args] => Array ( [0] => /usr/local/emhttp/plugins/tailscale/include/Pages/Tailscale.php [1] => Array ( ) ) ) [3] => Array ( [file] => /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(693) : eval()'d code [line] => 6 [function] => Tailscale\getPage [args] => Array ( [0] => Tailscale ) ) [4] => Array ( [file] => /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php [line] => 693 [function] => eval ) [5] => Array ( [file] => /usr/local/emhttp/plugins/dynamix/template.php [line] => 82 [args] => Array ( [0] => /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php ) [function] => require_once ) ) [previous:Error:private] => ) Pretty much all the tabs under Tailscale (Settings, Status, Lock, etc) give a similar error there too, with just different .php I think. It does appear to still be working/connecting though I think(?), as I can see both my unRAID servers in my active devices on other Tailscale clients and I can still connect to my remote server's unRAID GUI over the Tailscale IP.

I don't know if it is the same for older versions of vanilla, but I'd think so... For me at least I run Paper server which requires a non-vanilla server file. There is a variable in the docker config that should be "CUSTOM_JAR_PATH" and you want to set that to wherever your custom *.jar is, from the perspective of inside the container. That way it will override the default path to the server jar file, which is always the latest and updated (if needed) every time the container is restarted. For example, my /config container path is mapped to "/mnt/cache/appdata/minecraftserver-binhex", so all my files are under the /config directory inside the container, which is the standard/default. So then my "CUSTOM_JAR_PATH" is set to "/config/minecraft/paper_latest.jar". By doing that I can just grab the latest server jar file from the Paper website, drop it in /mnt/cache/appdata/minecraftserver-binhex/minecraft (the standard location for the server jar file to live) with the correct permissions, rename it to "paper_latest.jar", and I'm good to go to start the container up! That being said, I think you can do pretty much the same thing for any server jar, including one for an older version of vanilla or whatever you want.

I have the same question/issue. I like to go into the server console and issue a "save-all" and then "stop", before shutting off the container itself, just to have peace of mind of a clean save and shutdown. As of a couple months ago I noticed the same thing -- if I try to do a "stop" it shuts the MC server down but then it just immediately starts up again. If it matters, I'm using Paper for my server jar, though I have been for a long time without issue before this as well.

Something change with this JDownloader (JD) docker container or RapidGator (RG) lately, or has anyone else noticed this? I frequently use RG because it is about the only one that would pop up the captcha in the docker WebGUI and so was easy to use. But lately (this week?) it has not been popping up the captcha window for me to fill, so it just times out after awhile instead. Wondering if something changed from RG that JD can't pop up the captcha anymore to fill out or if it is maybe something broke in JD (mine or in general). Edit: Well luckily I was able to pull the captcha up in the MyJD app on my android phone. Weird though, as I've always been able to do the RG captchas right in the JD WebGUI in the past. Hopefully they are able to bring that back as the MyJD has not been the most reliable thing to use, but I'm glad it seems to be working today.

Updated plugins, including UD, earlier today and now I'm realizing I don't have the UD SMB shares anymore. Any thing change that could have caused this? I tried disabling SMB share on the disk and re-enabling it, but still nothing there. Running unRAID 6.9.2. edit: Huh, I was fiddling around and refreshed and now it has come back again... strange.

Updated this last night and now it doesn't seem to be starting up (or at least I can't tell as I can't get to it). I start it from the unRAID docker page and it shows running, but I just get a HTTP ERROR 400 page when trying to access the web GUI. The docker logs don't show any errors though. [migrations] started [migrations] no migrations found usermod: no changes ─────────────────────────────────────── ██╗ ███████╗██╗ ██████╗ ██║ ██╔════╝██║██╔═══██╗ ██║ ███████╗██║██║ ██║ ██║ ╚════██║██║██║ ██║ ███████╗███████║██║╚██████╔╝ ╚══════╝╚══════╝╚═╝ ╚═════╝ Brought to you by linuxserver.io ─────────────────────────────────────── To support LSIO projects visit: https://www.linuxserver.io/donate/ ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 99 User GID: 100 ─────────────────────────────────────── [custom-init] No custom files found, skipping... [ls.io-init] done. Tried restarting it multiple times and also tried just leaving it running for 30min+ to see if it would eventually go, but still the same thing. edit: Something with Chrome it seems. If I go to the webgui using Edge, it comes up fine.

Since I applied the latest update to this docker on Monday I get 100+ of these warnings a day. 2023-02-15 00:54:42 WARNING GENERICQUEUESCHEDULER-UPDATE-RECOMMENDED-ANILIST :: [918cfe7] Could not parse AniDB show, with exception: Traceback (most recent call last): File "/app/medusa/medusa/show/recommendations/anilist.py", line 95, in fetch_popular_shows recommended_show = self._create_recommended_show(show) File "</app/medusa/ext/decorator.py:decorator-gen-54>", line 2, in _create_recommended_show File "/app/medusa/ext/dogpile/cache/region.py", line 1577, in get_or_create_for_user_func return self.get_or_create( File "/app/medusa/ext/dogpile/cache/region.py", line 1042, in get_or_create with Lock( File "/app/medusa/ext/dogpile/lock.py", line 185, in __enter__ return self._enter() File "/app/medusa/ext/dogpile/lock.py", line 87, in _enter value = value_fn() File "/app/medusa/ext/dogpile/cache/region.py", line 977, in get_value value = self._get_from_backend(key) File "/app/medusa/ext/dogpile/cache/region.py", line 1265, in _get_from_backend self.backend.get_serialized(key) File "/app/medusa/ext/dogpile/cache/backends/file.py", line 217, in get_serialized with self._dbm_file(False) as dbm_obj: File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__ return next(self.gen) File "/app/medusa/ext/dogpile/cache/backends/file.py", line 213, in _dbm_file with dbm.open(self.filename, "w" if write else "r") as dbm_obj: File "/usr/lib/python3.10/dbm/__init__.py", line 91, in open raise error[0]("db type is {0}, but the module is not " dbm.error: db type is dbm.gnu, but the module is not available Anyone else getting these? I see a possible explanation and solution here, but thought I'd check before going ahead with deleting the *.dbm files from the cache folder and see if there are any other thoughts or ideas. edit: Deleted the dbm files and seems to be doing fine and so far no more 100+ errors a day.

Does wireguard only work with PIA? I use TorGuard and was thinking of maybe trying to switch to WG to see if it works better/is faster than using OVPN.

I've kind of seen similar things. I've been using this rTorrent container for a while (at least a couple years, probably more) with TorGuard VPN and it worked great up until recently. The past few months or so it just kind of stopped working well. I use Medusa and Radarr to grab stuff, but downloads have really fallen off. It takes a day or two sometimes for the magnets sent over from Medusa/Radarr to rTorrent to resolve into actual files (sometimes they never do even) and then it is a crapshoot whether the thing will actually download or not. I have to frequently manually go in and grab .torrent files, generally from rar bg, to catch up and when I load them in to rTorrent it doesn't seem to really work with the .torrent files at all, they just spin and never download or connect to the tracker (which may be due to the only tracker really being in there is rar bg). But I can load the same .torrent files in to my uTorrent v2.2.1 which runs on a Windows 10 VM with the TorGuard client on it, and things work fine there. I'm not really sure if the issue is rTorrent the program, the tracker(s), VPN, protocol, or something specific to the container, so it is hard to pinpoint where the problem lies.