Kognac

So, I am running into issues running multiple QBIT containers, I made sure to update the app directory to a new entry and changed all the ports to a new one for each instance and it will turn on run but im unable to access the webUI at all, I think it has something to do with the docker container ports not updating with the LAN ports that you can change in the setup process. Docker ports: LAN ports: Okay so I fixed it, I had to remove the Host Port 3 mapping and readd it using the new port needed for the web UI

For that many drives, you may as well do 2 parity HDs and 22 Array HDs. you probably arent going to be able to saturate your network read/writes to your array but that's why you should have a large nvme Cache pool that writes to your array and serves as a buffer for incoming content. read through the guides here to understand everything. https://docs.unraid.net/unraid-os/advanced-configurations/optimize-storage/zfs-storage/

Trying to restart the server to get docker back up and working again. When attempting to shutdown the array i get this error constantly while the array is trying to shutdown: Sep 17 00:01:04 Tower root: rmdir: failed to remove '/mnt/user': Directory not empty Sep 17 00:01:04 Tower emhttpd: shcmd (1757): exit status: 1 Sep 17 00:01:04 Tower emhttpd: shcmd (1759): rm -f /boot/config/plugins/dynamix/mover.cron Sep 17 00:01:04 Tower emhttpd: shcmd (1760): /usr/local/sbin/update_cron Sep 17 00:01:05 Tower emhttpd: Retry unmounting user share(s)... Sep 17 00:01:10 Tower emhttpd: shcmd (1761): /usr/sbin/zfs unmount -a Sep 17 00:01:10 Tower emhttpd: shcmd (1762): umount /mnt/user Sep 17 00:01:10 Tower root: umount: /mnt/user: not mounted. Sep 17 00:01:10 Tower emhttpd: shcmd (1762): exit status: 32 Sep 17 00:01:10 Tower emhttpd: shcmd (1763): rmdir /mnt/user Sep 17 00:01:10 Tower root: rmdir: failed to remove '/mnt/user': Directory not empty Checked if there were any ssh or terminal sessions open, none that i can tell, and no scripts running, and no open file transfers or open processes for smb/nfs (checked with lsof /mnt/user - no return in terminal via web) Before this issue, I had a disk starting to fail and was constantly erroring due to bad sectors. I shutdown the array and moved over a "fresh" disk from my unassigned devices and replaced disk 9 on the array. restarted the array which began the Parity rebuild of disk 9. After this started docker refused to run and gave this error: Sep 16 04:32:46 Tower emhttpd: error: malloc_share_locations, 8160: Operation not supported (95): getxattr: /mnt/user/appdata Sep 16 04:32:46 Tower emhttpd: error: malloc_share_locations, 8160: Operation not supported (95): getxattr: /mnt/user/data just continuous error up till the rebuild finished. and my docker app location changed from /mnt/user/appdata/Docker to /mnt/cache/appdata/Docker/ Just alot of weird issues and i wanted to restart the server to see if that helped clear up any of the oddities in order to get docker working again (I miss Plex). -****Well I fixed the issue by just force restarting the server and then enabling my user scripts after reinstalling my Docker apps. everything back up and working***

How’s it going?

Make sure to do option 2 after you stop the PMS Service.

Just let it run, it takes forever, especially with one your size. Binhex changed the script to be a hybrid of the one you linked and his own, so it just runs now off the command you ran. It will be better to salvage the Database then have to let plex rebuild. I have over 2k movies and a ton of tv shows and anime on mine and it took like a week to rebuild when my database got super corrupted about 6 months ago. And lost all the user watch history.

I believe you do have to keep the console window open, but yeah idk how large mine is but yours will take probably an hour or two.

Good luck! It should fix it your issue though. If you have a large database, be prepared for it to take forever though!

So I got it to work and then updated the steps I’ll make it more clear on an edit here in a sec. The deleted perms file was for a weird issue that you are unlikely having.

Yes, follow the steps and it’s really easy, I updated the steps I took on a previous post you can find on my profile on this topic.

Same, but hasn’t happened to me in a day or two now.

Try repairing the database it’s pretty quick to do and it will most likely resolve your issue because I had the same thing happened to me took about an hour for it to fix itself.

@milkmandan That would normally be due to CPU issues, at least those errors but normally those dont cause the docker to crash and burn unless you have it limited to that one core. It is a really old CPU though to be fair.

2025-06-13 22:35:14,172 DEBG 'start-script' stdout output: [info] Successfully retrieved external IP address 10.10.10.40 2025-06-13 22:35:14,173 DEBG 'start-script' stdout output: [info] Script started to assign incoming port for 'protonvpn' 2025-06-13 22:35:14,176 DEBG 'start-script' stdout output: [info] WireGuard interface 'up' 2025-06-13 22:35:16,233 DEBG 'start-script' stdout output: initnatpmp() returned 0 (SUCCESS) using gateway : 10.0.0.1 sendpublicaddressrequest returned 2 (SUCCESS) readnatpmpresponseorretry returned 0 (OK) Public IP address : 10.10.10.52 epoch = 796801 closenatpmp() returned 0 (SUCCESS) 2025-06-13 22:35:17,115 DEBG 'watchdog-script' stdout output: [info] qBittorrent listening interface IP 0.0.0.0 and VPN provider IP 10.0.0.2 different, marking for reconfigure 2025-06-13 22:35:17,128 DEBG 'watchdog-script' stdout output: [info] qBittorrent not running 2025-06-13 22:35:17,128 DEBG 'watchdog-script' stdout output: [info] qBittorrent incoming port 6881 and VPN incoming port 33000 different, marking for reconfigure so i don't know why but the script is not updating the public ip

So i had a similar issue and it was due to me setting the MAX HTTP announce way to high (set it to 50), check and see if that setting under the advanced settings (in the webUI) towards the bottom is > 50.

So something odd I have noticed is that it seems the port assigned via the VPN (proton) isnt updating on the qbit container correctly, I was having a weird tracker connectivity issue where I had to manually set the Incoming port on the configuration in unraid, and after I did that everything started connecting correctly. Thankfully with proton the Port assigned doesnt normally change if you do a quick disconnect and reconnect (IE restarting the container) There wasn't really any logs about it, qbit seemed to think it had correctly assigned the port: 2025-06-13 13:39:59,562 DEBG 'start-script' stdout output: [info] Script started to assign incoming port for 'protonvpn' 2025-06-13 13:39:59,566 DEBG 'start-script' stdout output: [info] WireGuard interface 'up' 2025-06-13 13:40:01,629 DEBG 'start-script' stdout output: initnatpmp() returned 0 (SUCCESS) using gateway : 10.0.0.0 sendpublicaddressrequest returned 2 (SUCCESS) readnatpmpresponseorretry returned 0 (OK) Public IP address : *.*0.0 epoch = 000000 closenatpmp() returned 0 (SUCCESS) 2025-06-13 13:40:02,490 DEBG 'watchdog-script' stdout output: [info] qBittorrent listening interface IP 0.0.0.0 and VPN provider IP 10.0.0.0 different, marking for reconfigure 2025-06-13 13:40:02,502 DEBG 'watchdog-script' stdout output: [info] qBittorrent not running 2025-06-13 13:40:02,503 DEBG 'watchdog-script' stdout output: [info] qBittorrent incoming port 6881 and VPN incoming port 33333 different, marking for reconfigure 2025-06-13 13:40:02,505 DEBG 'watchdog-script' stdout output: [info] qBittorrent config file already exists, skipping copy [info] Removing session lock file (if it exists)... 2025-06-13 13:40:02,577 DEBG 'watchdog-script' stdout output: [info] Attempting to start qBittorrent... 2025-06-13 13:40:02,586 DEBG 'watchdog-script' stdout output: [info] qBittorrent process started [info] Waiting for qBittorrent process to start listening on port 8080... 2025-06-13 13:40:55,637 DEBG 'watchdog-script' stdout output: [info] qBittorrent process listening on port 8080 But in the logs on the Web UI i see this before I manually assigned the port in the unraid qbit config on the webportal: [CRITICAL] Failed to listen on IP. IP: "10.0.0.0". Port: "TCP/33333". Reason: "Address already in use" also was unable to manually assign the Port in the Qbit Web UI for the incoming port, it still was displaying the old port from when my internet reconnected last night. Even though according to the old logs it had gone though the same steps of reconnecting and reassigning the new port. Another thing I have noticed aswell is that it is somehow using two IPs over the VPN, I dont know how that is possible but I see it using two different IPs on a website.

Check and see if the Repository is set to: binhex/arch-plexpass:latest

I am still having this issue, running the dbrepair.sh appears to do nothing as well since I went through all the steps and it didn't help fix anything. *** steps used to fix Database corruption*** How to start a DbRepair Within the Plex Console, Type: DBRepair.sh These are the options, you likely only need to do the first two, Option 1 and 2. Select 1 - 'stop' - Stop PMS. 2 - 'automatic' - Check, Repair/Optimize, and Reindex Database in one step. 3 - 'check' - Perform integrity check of database. 4 - 'vacuum' - Remove empty space from database without optimizing. 5 - 'repair' - Repair/Optimize databases. 6 - 'reindex' - Rebuild database indexes. 7 - 'start' - Start PMS 8 - 'import' - Import watch history from another database independent of Plex. (risky). 9 - 'replace' - Replace current databases with newest usable backup copy (interactive). 10 - 'show' - Show logfile. 11 - 'status' - Report status of PMS (run-state and databases). 12 - 'undo' - Undo last successful command. 21 - 'prune' - Remove old image files (jpeg,jpg,png) from PhotoTranscoder cache & all temp files left by PMS. 42 - 'ignore' - Ignore duplicate/constraint errors. 88 - 'update' - Check for updates. 98 - 'quit' - Quit immediately. Keep all temporary files. 99 - 'exit' - Exit with cleanup options. Select Option 1 to stop the Plex Media Service(PMS) then select Option 2 and it should fix your database with minimal input. Nothing seems to be working (testing deleting the perms.txt file to see if that helps), and I would really not like to rebuild the Plex database again, It took forever last time, about a week to fully rebuild. Going back to branch: 1.41.5.9522-1-01 fixes the issue, but I would like to get to the latest releases again. ***okay update the next morning, So last night I was able to get it to start working correctly. I fixed it by deleting the perms.txt document and then after restart it was able to recognize and read the database.

I do

Still having this issue, tried to use a backup, but I get the same error. tried today going back to the latest branch.

Plex server is local, no changes to it really. but the reinstall didnt work.

So tried changing to SSL connection, nothing. just spins and tried to remove token and refresh it basically but it doesnt detect any servers. Maybe ill try the good old uninstall and reinstall

Ajax: <pre>array(1) { [0]=> string(133) "https://IP:32400/status/sessions?X-Plex-Token=TOKEN_m=1744312685" } </pre><pre>array(1) { [0]=> string(133) "https://IP:32400/media/subscriptions/scheduled?X-Plex-Token=TOKEN } </pre><pre>array(2) { [0]=> string(133) "https://IP:32400/status/sessions?X-Plex-Token=TOKEN_m=1744312685" [1]=> string(135) "https://IP:32400/status/sessions?X-Plex-Token=TOKEN_m=1744312685" } </pre><pre>array(2) { [0]=> string(133) "https://IP.:32400/media/subscriptions/scheduled?X-Plex-Token=TOKEN" [1]=> string(135) "https://IP.:32400/media/subscriptions/scheduled?X-Plex-Token=TOKEN" } </pre><pre>array(3) { [0]=> string(133) "https://IP.:32400/status/sessions?X-Plex-Token=TOKEN_m=1744312685" [1]=> string(135) "https://IP.32400/status/sessions?X-Plex-Token=TOKEN_m=1744312685" [2]=> string(80) "IP:32400/status/sessions?X-Plex-Token=TOKEN_m=1744312685" } </pre><pre>array(3) { [0]=> string(133) "https://IP.:32400/media/subscriptions/scheduled?X-Plex-Token=TOKEN" [1]=> string(135) "https://IP:32400/media/subscriptions/scheduled?X-Plex-Token=TOKEN" [2]=> string(80) "IP:32400/media/subscriptions/scheduled?X-Plex-Token=TOKEN" } </pre><pre>string(83) "<?xml version="1.0" encoding="UTF-8"?> <MediaContainer size="0"> </MediaContainer> " </pre><pre>string(0) "" </pre><pre>string(83) "<?xml version="1.0" encoding="UTF-8"?> <MediaContainer size="0"> </MediaContainer> " </pre><pre>string(83) "<?xml version="1.0" encoding="UTF-8"?> <MediaContainer size="0"> </MediaContainer> " </pre><pre>string(0) "" </pre><pre>string(83) "<?xml version="1.0" encoding="UTF-8"?> <MediaContainer size="0"> </MediaContainer> " </pre><pre>array(0) { } </pre>[] getServers: <pre>string(61) "https://plex.tv/devices.xml?X-Plex-Token=TOKEN" </pre>{"serverList":{"bd5***":{"Name":"plex-home","Identifier":"bd5***","Connections":[]},"a90***":{"Name":"plex-home","Identifier":"a90***","Connections":[]},"f8b***":{"Name":"plex-home","Identifier":"f8b***","Connections":[]},"73b***":{"Name":"plex-home","Identifier":"73b***","Connections":[]},"894***":{"Name":"Plex","Identifier":"894***","Connections":[]}}}

Nevermind, what information should I keep private? Just the Plex Token?