-
[Support] binhex - qBittorrentVPN
This was my first thought as well but unfortunately didn't work. I copied over from the old .conf to the new file section by section, keeping any lines from the new file that did not exist in the old, testing along the way. I now have it working and narrowed down to just one line that makes the difference. WebUI\CSRFProtection=false My old conf file has WebUI\CSRFProtection=true, with everything else in the new file being the same I can not log in with this setting enabled. When I change it to false I can log in normally Idk what CSRFProtection is and if its important, I haven't looked into yet but at least i can log in now. I'll see what I can learn from the qbit forum and/or github page
-
[Support] binhex - qBittorrentVPN
This did the trick. After renaming the qbittorrent.conf file and restarting the container a new version of the file was created. A new temp password appeared in the supervisord log and I was able to log in with the new temp password and reset the password in the UI. Now the question is what to do about my prefs? Simply changing the new .conf name to something else and my existing .conf to the proper name made me unable to log in again with any password. There are many entries in my existing .conf that do not exist in the fresh one so I do not know which parts I actually need or which part is the source of the issue. I'll keep noodling at it but I would appreciate if anyone has further advice
-
[Support] binhex - qBittorrentVPN
I added it back in again. The original default 'adminadmin' does not work, my previously set password still stored in my pw manager does not work, and the supervisord log no longer shows a temp password on startup for me to try.
-
[Support] binhex - qBittorrentVPN
No, I removed it based on this https://github.com/qbittorrent/qBittorrent/wiki/Web-UI-password-locked-on-qBittorrent-NO-X-(qbittorrent-nox) So it is still required then? When it was there my previously set password would not work anymore
-
[Support] binhex - qBittorrentVPN
Correct, Username: admin and the temp password do not work. If i stop and restart the container I get a new temp password in the logs each time. I have attempted multiple times with no success
-
[Support] binhex - qBittorrentVPN
Hello, I am unable to log in to the container UI. Are the old work-arounds from November still needed? Edit: Just for clarity, I am able to access the login page and do not seem to have the vpn problems that seem to be affecting others recently I went through the work-arounds shared a few months back when the default adminadmin password was killed and had everything working. My server was shutdown for a week+ for a move and I updated the container when I got back up and running and could no longer login with my previously set password or the old default. I can access the temp password under the supervisord.log file but am unable to login with that either; I seem to remember not being able to access that previously thus the stickied work-arounds but maybe I am mistaken on that. Is the stickied work-around post still necessary or is there something else I am missing? The work around I am referring to: Adding this line under [Preferences], in the config file, works, for setting the default password manually to: adminadmin WebUI\Password_PBKDF2="@ByteArray(ARQ77eY1NUZaQsuDHbIMCA==:0WMRkYTUWVT9wVvdDtHAjU9b3b7uB8NR1Gur2hmQCvCDpm39Q+PsJRJPaCU51dEiz+dTzh8qbPsL8WkFljQYFQ==)" qbit-supervisord.log
-
[Support] binhex - Jackett
Hello, I am having a new issue with this docker in the last few days. The container will show as started but I can not access the UI and the arrs cannot access the indexers. The log indicates the "inotify limit has been reached" I don't know anything about this and couldn't find that term in a search of this thread at all. I first found the problem yesterday, tried several things including deleting and reinstalling the container to no avail. Eventually I rebooted ther server and that resolved the issue but it has now returned again after less than 24hrs. Can anyone help? Here is the ful log from the container: 2023-07-10 16:58:44,346 DEBG 'jackett' stderr output: Unhandled exception. 2023-07-10 16:58:44,346 DEBG 'jackett' stderr output: System.IO.IOException: The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached. at System.IO.FileSystemWatcher.StartRaisingEvents() at System.IO.FileSystemWatcher.StartRaisingEventsIfNotDisposed() at System.IO.FileSystemWatcher.set_EnableRaisingEvents(Boolean value) at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.TryEnableFileSystemWatcher() at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.CreateFileChangeToken(String filter) at Microsoft.Extensions.FileProviders.PhysicalFileProvider.Watch(String filter) at Microsoft.Extensions.Configuration.FileConfigurationProvider.<.ctor>b__1_0() at Microsoft.Extensions.Primitives.ChangeToken.OnChange(Func`1 changeTokenProducer, Action changeTokenConsumer) at Microsoft.Extensions.Configuration.FileConfigurationProvider..ctor(FileConfigurationSource source) at Microsoft.Extensions.Configuration.Json.JsonConfigurationSource.Build(IConfigurationBuilder builder) at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build() at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors) at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build() at Jackett.Server.Program.Main(String[] args) 2023-07-10 16:58:44,350 DEBG 'jackett' stderr output: /home/nobody/start.sh: line 4: 90 Aborted /usr/lib/jackett/jackett --NoRestart --NoUpdates --DataFolder /config/Jackett 2023-07-10 16:58:44,350 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22718703981712 for <Subprocess at 22718704013456 with name jackett in state STARTING> (stdout)> 2023-07-10 16:58:44,351 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22718702056336 for <Subprocess at 22718704013456 with name jackett in state STARTING> (stderr)> 2023-07-10 16:58:44,351 WARN exited: jackett (exit status 134; not expected) 2023-07-10 16:58:44,351 DEBG received SIGCHLD indicating a child quit 2023-07-10 16:58:47,354 INFO spawned: 'jackett' with pid 98 2023-07-10 16:58:47,652 DEBG 'jackett' stdout output: 07-10 16:58:47 Info Starting Jackett v0.21.446 2023-07-10 16:58:47,656 DEBG 'jackett' stdout output: 07-10 16:58:47 Info Jackett Data will be stored in: /config/Jackett 2023-07-10 16:58:47,791 DEBG 'jackett' stdout output: 07-10 16:58:47 Error System.IO.IOException: The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached. [v0.21.446.0] System.IO.IOException: The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached. 2023-07-10 16:58:47,791 DEBG 'jackett' stdout output: at System.IO.FileSystemWatcher.StartRaisingEvents() at System.IO.FileSystemWatcher.StartRaisingEventsIfNotDisposed() at System.IO.FileSystemWatcher.set_EnableRaisingEvents(Boolean value) at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.TryEnableFileSystemWatcher() at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.CreateFileChangeToken(String filter) at Microsoft.Extensions.FileProviders.PhysicalFileProvider.Watch(String filter) at Microsoft.Extensions.Configuration.FileConfigurationProvider.<.ctor>b__1_0() at Microsoft.Extensions.Primitives.ChangeToken.OnChange(Func`1 changeTokenProducer, Action changeTokenConsumer) at Microsoft.Extensions.Configuration.FileConfigurationProvider..ctor(FileConfigurationSource source) at Microsoft.Extensions.Configuration.Json.JsonConfigurationSource.Build(IConfigurationBuilder builder) at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build() at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors) at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build() at Jackett.Server.Program.Main(String[] args) 2023-07-10 16:58:47,792 DEBG 'jackett' stderr output: Unhandled exception. 2023-07-10 16:58:47,792 DEBG 'jackett' stderr output: System.IO.IOException: The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached. at System.IO.FileSystemWatcher.StartRaisingEvents() at System.IO.FileSystemWatcher.StartRaisingEventsIfNotDisposed() at System.IO.FileSystemWatcher.set_EnableRaisingEvents(Boolean value) at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.TryEnableFileSystemWatcher() at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.CreateFileChangeToken(String filter) at Microsoft.Extensions.FileProviders.PhysicalFileProvider.Watch(String filter) at Microsoft.Extensions.Configuration.FileConfigurationProvider.<.ctor>b__1_0() at Microsoft.Extensions.Primitives.ChangeToken.OnChange(Func`1 changeTokenProducer, Action changeTokenConsumer) at Microsoft.Extensions.Configuration.FileConfigurationProvider..ctor(FileConfigurationSource source) at Microsoft.Extensions.Configuration.Json.JsonConfigurationSource.Build(IConfigurationBuilder builder) at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build() at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors) at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build() at Jackett.Server.Program.Main(String[] args) 2023-07-10 16:58:47,797 DEBG 'jackett' stderr output: /home/nobody/start.sh: line 4: 100 Aborted /usr/lib/jackett/jackett --NoRestart --NoUpdates --DataFolder /config/Jackett 2023-07-10 16:58:47,797 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 22718716840784 for <Subprocess at 22718704013456 with name jackett in state STARTING> (stdout)> 2023-07-10 16:58:47,797 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 22718702002960 for <Subprocess at 22718704013456 with name jackett in state STARTING> (stderr)> 2023-07-10 16:58:47,798 WARN exited: jackett (exit status 134; not expected) 2023-07-10 16:58:47,798 DEBG received SIGCHLD indicating a child quit 2023-07-10 16:58:48,799 INFO gave up: jackett entered FATAL state, too many start retries too quickly
-
Cache pool problems
tower-diagnostics-20220214-1220.zip
-
Cache pool problems
I have been running my system with a single 256gb SSD cache drive. I have a 512gb SSD repurposed from another system that I wanted to add to my cache pool. Once the new drive was added I had a cache pool total size of 384GB but the used/free space figures only added up to 256GB After some research what ive learned is that my cache pool should be 256GB same as the smallest drive (I hadn't researched this beforehand at all so I didn't know about the btrfs file system and the cache pool being in raid) I decided I'd prefer to have the 512GB alone as my cache drive and use the 256GB as a separate pool for VM data. Now that the drives have been split (one as Cache and the other as VMPool) they are behaving as duplicates. Both devices still showing a size of 384GB but 256GB in used/free and data add to or removed from one is duplicated on the other. Please help me stop this. I want the drives to be fully separate pools of their full size. I've removed and re-added the drives which didn't help. Do I need to format the drives? I haven't seen where I would do this
-
Meatball Flag started following 67500 UDMA CRC Errors during preclear!
-
67500 UDMA CRC Errors during preclear!
I recently picked up a new WD 14tb External drive, which I intend to shuck. Before I open the enclosure I am running the drive through a preclear which is nearly done with the pre-read stage. I have a series of alerts in Unraid showing the drive has 67500 UDMA CRC errors. Some googling and forum reading indicates that these errors are not uncommon and are often attributed to failing data cables. With the drive still in its enclosure should I be considering an RMA for this? How serious should I take these errors? Edit: From the logs Nov 30 20:13:18 Tower kernel: blk_update_request: critical medium error, dev sdb, sector 24757529272 op 0x0:(READ) flags 0x80700 phys_seg 9 prio class 0
Meatball Flag
Members
-
Joined
-
Last visited