Kosslyn

I cannot get this figured out so I am coming here for help. I was swapping batteries in my UPS 2 days ago when I accidentally turned off the UPS instead of starting a self-test. Server was hard shut off and then I rebooted it and it performed parity check and everything came out ok until I realized today that I cannot access my deluge containers (I have 3). I have gone through the logs and it seems like it was running fine until the hard shutdown and now the logs loop after an Inactivity Timeout. I have combed the logs and cannot find a reason why. I have already downloaded fresh "ca.crt", "ta.key", and ovpn files and have even changed my user name and pass and entered the new ones. It seems to be an issue with my VPN connection as I can access the GUI if I turn off VPN, but when it is on, it will not connect. LAN is 192.168.1.0/24. I have double checked the info by making a new VPN connection on my desktop and it connects fine. supervisord.log

I honestly can't help a lot with this, but I have noticed that when I reboot my windows vm with a 5700xt passed through, I get the reset bug and a server reboot does not fix it. I have to shut down the server wait at least 5 sec and then power it back up. When I just reboot the server, the led on the 5700xt don't go off so the gpu is always receiving power and never clears the bug. Try a shut down and wait for the led to go off for a few sec and then power up and see if that fixes at least that issue. For the others, if you think you corrupted some files you can always reinstall unraid on the usb and keep your current config to see if fresh files fixes that. I believe it's a similar procedure to upgrading unraid manually.

I have Plex in a docker with no hardware acceleration and I was having corruption before moving appdata to an unassigned drive.

Here also. Corrupted anytime I hit it with an io load (ie rebuilding Plex from scratch) less corruption in sonarr and radarr but still present. No corruption when I moved back to 6.6.7. hardware forced me back to 6.7.2 and got corruption again. Nothing since I moved appdate to an unnasigned nvme. Going on a few weeks.

As a stop gap, I put in a 5400rpm laptop spinning rust drive and used it as an unnasigned disk for my appdata for about a week. During that week plex was slow to load items and felt a little sluggish (expected), but at the end of a week, I still had no corruption. I rebuilt my docker twice in that time and let it auto import my entire library both times. I stopped the import the second time after about 18hrs and it still hadn't finished importing everything. I hit it with more than 550 movies, more than 4000 tv episodes, less than 1000 songs, and well over 6000 pictures. While importing, the console had a bunch of "took to long" and "waited one whole second for busy database" and after hours of that and chugging through my files, the database still had no corruption. I think the leading theory already had to do with unraid fs, but I guess here's some more confirmation. Obviously with limetech replies on the matter being fairly sparse and no idea when a fix is coming, I didn't want to deal with 5400rpm slim sata drive speeds for my database so I am now rebuilding plex from scratch on an nvme drive and the console is show a few "held transaction for to long" warnings, but it's going much faster on import.

Thank you! So far as I understand it, there is no way to have files on cache and on the array (i.e. duplicate), correct? The cache is a write only cache and there is no way to set it up as a tiered file system or have files live on cache, but then have basically a snapshot of cache stored onto the array without removing the files from cache, correct? Using "yes" for cache would never move the files to the array and using "prefer" would also not move the files from cache onto the array (unless the cache fills up). And if we use "prefer" and cache fills up, then once it is cleared, the files move back to cache but are then removed from the array, correct?

For some reason my google-fu was failing me so I decided not to risk it. If I write to /mnt/cache without a cache disk then it writes to ram, correct? If I write there with a cache disk, then it writes to the disk and the data persists even through restarts and power loss? And so far there still isn't anyone who has had an issue with the db's while running from /mnt/cache, correct? I figured another reason for using unassigned devices was that Unraid didn't touch the disk at all and it'd be safe from this and most future bugs. I don't mind getting the smallest nvme I can find and just putting that as a unassigned device for appdata so that I know everything is safe. Is this a bad idea? Anything I'm missing? I've also hit 2 other issues with 6.7.x so I'm trying to get those figured out, but I'm going to add back a cache disk at some point.

I had downgraded to 6.6.7 after i spent days with corrupted databases in plex, sonarr, and radarr. but I needed to upgrade to 6.7.x for some new hardware I got and am now having the same corruption issues. Following this thread, I moved my appdata to cache disk, but then lost everything due to a restart. I then rebuilt from backups. I ran appdata from cache for 2 days with no corruptions. I rebuilt plex from the ground up twice. Usually importing all my video and audio would cause a corruption error, but running from cache, it did not corrupt. However due to loosing data on power loss, I decided to put an old hard drive into the server as an unassigned drive and have mounted that to use exclusively for appdata. I'm hoping that since it isnt included whatsoever in the array and the fs doesn't touch this drive, my db's will be safe. I'll update if I find any corruption.

I am having the same problem. I've tried a few things from different forums and nothing is working. I even tried setting up a binhex plex docker and that wouldn't boot either. I don't know if it an issue across the board or not. added: Sonarr and Radarr are both down as well. I believe it is an issue with unraid. I found some mention of sqlite3 errors in the logs and that seems to be broken by enabling "directIO" which i did this morning. It somehow corrupts the sqlite3 database which affects all 3 dockers. Some people are saying it happens if your /config location is inside of mnt/user instead of mnt/cache. I changed the /config location and I am still having the same issue. I haven't found a solution that has worked for me yet. Solved: Turns out, it did fix the issue. so what I did was: 1. copy the files for whatever docker(s) went down from "mnt/user/appdata/(docker)" to "mnt/cache/appdata/(docker)" 2. change the "/config" location for the docker(s) you moved to the new location: "mnt/cache/appdata/"(docker)" 3. start the docker(s) and they should retain all of the old setup and start correctly. note: if you don't copy over the appdata folder(s), none of the old setup will be retained.