augot

Posting this here for anyone else who was worried about a bunch of "new" errors showing in the Overview page of Admin Settings since upgrading to v28. Apparently this is an intended behavior since the update to the new version (according to this post on the main Nextcloud support forum from one of the devs). Those errors were apparently always there in the log, but in v28 onwards a decision was made to put an alert on the Overview page for admins since you'd otherwise not see errors were happening unless you went digging in the log manually (or had set up some other kind of alerts notification system). Personally, I discovered that my error number kept going up because a couple of videos had become corrupted when backing up from my iPhone, and Memories was failing to index them/ffmpeg was unable to generate preview thumbnails. Since they were trying to do this every hour on the hour, it meant I had a handful of new errors every hour. Deleting the corrupted versions and reuploading clean versions from my phone again fixed it. If you're seeing lots of errors, don't panic that it necessarily means something super serious, but it seems like we're being given a nudge by the Nextcloud devs to take a more proactive approach to being admins (and personally, since it saved me accidentally deleting some stuff I thought I had safely backed up, I'm grateful!), although there is currently discussion over whether there's a better way to handle these notifications without spooking people so much/giving more granular information about what exactly is wrong. Also - the blank log page seems to be an unrelated caching issue. Mine eventually resolved itself on its own, but lots of people over there say their logs reappeared once they cleared their browser caches.

Is there a setting somewhere within Tdarr (or the Docker template) to get it to work with Recycle Bin? Old files are being deleted fully instead of moved into the bin when replaced with new, transcoded versions, and I'm wary of letting it go on my entire library without that safety net.

I'm also having a similar issue since the latest update (28.0.0) - the security warning on the admin overview page is reporting a steadily increasing number of errors in the log, but the log page itself is blank. The log is still being written to (I've looked it up directly on my server), and everything else in my instance seems to be working OK? Still, it's weird.

This is the weird thing - I found that unless I also unplugged the USB cable into my PSU, those lines kept getting re-added to the config file whenever I re-ran sensors (or changed things via the plugin GUI), even if I never selected them to be added. And that was even after removing the CorsairPSU plugin too. So weird!

Anyone have an idea what might cause my router to start blocking Plex, but specifically only the app.plex.tv browser app? Not sure when it started happening because 99% of my usage is via TV/device apps, and also because the localip:32400 connection for the GUI via docker still works and I'm more likely to use that than the app.plex.tv URL. But anything that tries to connect to app.plex.tv via a browser (PC or phone) on my home network gets a "No content available. Check your network connection and verify that any media servers are online." error. Everything else works totally fine, including app.plex.tv from outside my network. So I figure it must be something to do with my router. Nothing's changed in my router's settings that I can identify. Port forwarding rules are the same as they've always been, no new settings or rules have appeared that relate to either Plex or my server. Any ideas? EDIT: Ignore me, it was the DNS rebind issue. My ISP allocated me a new static IP a few weeks ago and I assume they also updated their DNS service to block Plex requests. Changed to Google's DNS in my router settings and it works fine now.

Yep, but also the PSU itself - it was still happening even after I removed the plugin. Had to unplug the USB from the PSU so the sensors weren't picked up at all. Weird bug!

Did you ever find a solution to this? I've started having the exact same problem since the 6.12.* releases came out. x570 Taichi board, all temps and fan speeds were monitored absolutely fine for months before this. If I run 'sensors-detect' in the CLI then reboot, then run 'sensors', I get normal output: nct6798-isa-0290 Adapter: ISA adapter in0: 344.00 mV (min = +0.00 V, max = +1.74 V) in1: 1.68 V (min = +0.00 V, max = +0.00 V) ALARM in2: 3.44 V (min = +0.00 V, max = +0.00 V) ALARM in3: 3.25 V (min = +0.00 V, max = +0.00 V) ALARM in4: 1.81 V (min = +0.00 V, max = +0.00 V) ALARM in5: 1.10 V (min = +0.00 V, max = +0.00 V) ALARM in6: 1.19 V (min = +0.00 V, max = +0.00 V) ALARM in7: 3.44 V (min = +0.00 V, max = +0.00 V) ALARM in8: 3.30 V (min = +0.00 V, max = +0.00 V) ALARM in9: 1.62 V (min = +0.00 V, max = +0.00 V) ALARM in10: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in11: 632.00 mV (min = +0.00 V, max = +0.00 V) ALARM in12: 936.00 mV (min = +0.00 V, max = +0.00 V) ALARM in13: 920.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 904.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 0 RPM (min = 0 RPM) fan2: 837 RPM (min = 0 RPM) fan3: 1229 RPM (min = 0 RPM) fan4: 2122 RPM (min = 0 RPM) fan5: 509 RPM (min = 0 RPM) fan6: 2854 RPM (min = 0 RPM) fan7: 381 RPM (min = 0 RPM) SYSTIN: +43.0°C sensor = thermistor CPUTIN: +36.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +16.0°C sensor = thermistor AUXTIN1: -61.0°C sensor = thermistor AUXTIN2: +12.0°C sensor = thermistor AUXTIN3: +31.0°C sensor = thermistor SMBUSMASTER 1: +69.0°C (high = +105.0°C, hyst = +95.0°C) SMBUSMASTER 0: +41.0°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C TSI0_TEMP: +41.0°C TSI1_TEMP: +69.2°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled k10temp-pci-00c3 Adapter: PCI adapter Tctl: +41.8°C Tccd1: +42.5°C Tccd2: +36.8°C corsairpsu-hid-3-1 Adapter: HID adapter v_in: 230.00 V v_out +12v: 11.98 V (crit min = +8.41 V, crit max = +15.59 V) v_out +5v: 5.03 V (crit min = +3.50 V, crit max = +6.50 V) v_out +3.3v: 3.30 V (crit min = +2.31 V, crit max = +4.30 V) psu fan: 0 RPM vrm temp: +41.8°C (crit = +70.0°C) case temp: +32.5°C (crit = +70.0°C) power total: 176.00 W power +12v: 134.00 W power +5v: 36.00 W power +3.3v: 7.00 W curr +12v: 11.25 A (crit max = +100.00 A) curr +5v: 7.44 A (crit max = +40.00 A) curr +3.3v: 2.19 A (crit max = +40.00 A) They also all appear in the GUI dropdown. However, as soon as I select any and hit save/apply, they then disappear, and 'sensors' delivers this: Error: File /etc/sensors.d/sensors.conf, line 9: Undeclared bus id referenced sensors_init: Can't parse bus name Only rebooting brings them back. EDIT: Oh my god I think I fixed it. The issue seems to be the sensors on my Corsair PSU, which were listed in line 9 of my sensors.conf. Here's my process - using midnight commander, I navigated to /etc/sensors.d/sensors.conf. Completely fresh after a new sensors-detect run, it looks like this: # sensors chip "nct6798-isa-0290" ignore "temp9" chip "nct6798-isa-0290" ignore "temp10" chip "nct6798-isa-0290" ignore "fan1" chip "corsairpsu-hid-3-1" ignore "fan1" Deleting lines 9 and 10 (corsairpsu and its associated fan sensor) and saving immediately returns all other sensors to the GUI dropdown. If I select the fans, CPU, and mobo temp sensors I want, and hit save, they again all disappear from the GUI. However, I can then reopen sensors.conf in mc and see that the corsairpsu sensor has snuck back in along with the other sensors I actually selected in the GUI. Deleting that line again (and also its associated "ignore fan" line) both returns all options to the GUI and makes the relevant temps/fan speeds reappear throughout the system GUI. 2nd EDIT: Unfortunately this does not persist between reboots, but only because the corsairpsu line is re-added to sensors.conf. Deleting it again restores normal functionality.

Riiight, gotcha - conceptually parity works more like it does in the Unraid array (but striped across all disks) rather than the "two copies" version I had in my head. Thanks for clearing up.

Not really a problem as such, but I've just set up a new ZFS pool to try out some of these new features I've heard so much about, and I had a bit of a pleasant surprise. 3 x 2TB SSDs, running RAID-Z, so I had assumed that it would give me a total pool capacity of around 3TB. But it's actually 3.9TB total? Just wondering how the pool could cope with the loss of one drive, with two "copies" of everything, when the total disk space is only 6TB, not 7.8TB...

Ah I came here to post about having this exact issue, glad to see it's already been identified and solved in the new release.

I see - thank you for clarifying.

I see - thank you for clarifying.

Excited to upgrade and finally see what all the fuss is about with ZFS. If I wanted to switch one of my array disks from XFS to ZFS, is it as simple as unbalancing everything off it, stopping the array, formatting the empty disk, then restarting the array and unbalancing everything back onto it? Or will that also destroy parity and require a rebuild of that too?

Upgraded from 6.11.4 to 6.11.5 without any issues except that it still says "Starting services..." on the bottom bar on the GUI dashboard. Can't see anything in the log that hasn't started yet (server's been up for a few hours now) so not sure if it's a graphical bug or not:

Having a weird issue. Not sure when it started but must have been within the last few weeks. Radarr's log is reporting that it doesn't have permission to access the directory assigned to /trash in the Docker template (a default directory defined by the Recycle Bin plugin), so every time it grabs something that's an upgrade for an existing file it can't delete that existing file, and the import fails. It used to be able to delete files fine, nothing's changed in how the Docker template is setup, and the exact same settings with Sonarr don't cause an issue (both container template settings and Media Management settings in-app). Even weirder - I didn't notice it for a while because it seems to work again if the container is restarted (although not always, it can take a few restarts), until eventually it gums up once more. Radarr is also fine creating entirely new directories and moving fresh files into them at all times. Here's an example log from today: 2022-05-20 11:20:33.9|Warn|ImportApprovedMovie|Couldn't import movie /data/completed/[filename].mkv [v4.1.0.6175] System.UnauthorizedAccessException: Access to the path '/trash/[movie name]' is denied. ---> System.IO.IOException: Permission denied --- End of inner exception stack trace --- at System.IO.FileSystem.CreateDirectory(String fullPath) at System.IO.Directory.CreateDirectory(String path) at NzbDrone.Common.Disk.DiskProviderBase.CreateFolder(String path) in D:\a\1\s\src\NzbDrone.Common\Disk\DiskProviderBase.cs:line 189 at NzbDrone.Core.MediaFiles.RecycleBinProvider.DeleteFile(String path, String subfolder) in D:\a\1\s\src\NzbDrone.Core\MediaFiles\RecycleBinProvider.cs:line 94 at NzbDrone.Core.MediaFiles.UpgradeMediaFileService.UpgradeMovieFile(MovieFile movieFile, LocalMovie localMovie, Boolean copyOnly) in D:\a\1\s\src\NzbDrone.Core\MediaFiles\UpgradeMediaFileService.cs:line 62 at NzbDrone.Core.MediaFiles.MovieImport.ImportApprovedMovie.Import(List`1 decisions, Boolean newDownload, DownloadClientItem downloadClientItem, ImportMode importMode) in D:\a\1\s\src\NzbDrone.Core\MediaFiles\MovieImport\ImportApprovedMovie.cs:line 123 Any ideas?

Upgraded from rc4, all good so far. Also seems to have fixed a persistent bug I had where every time I rebooted, Dynamix Auto Fan would randomly reassign the disks being monitored for temps, and I'd have to re-sort them again.

Wanted to bump this just to give a final update after managing to solve the issue, for anyone who might experience something similar in future and google this. The problem WAS the RAM in the end. After my last post, the system unfortunately locked up again after a couple of days and the unmountable disks issue returned. I decided to start again from the beginning, in case one of my original troubleshooting steps had missed something obvious - and since I'd run memtest as one of the very first things, I repeated that again (even though the first time around it had run repeatedly without finding any errors). But this time... so many errors that it halted testing within less than a minute of starting. *Three* of my four sticks of RAM, it turned out, were so badly broken that it's a miracle I was even able to boot. Why didn't anything show up the first time? I haven't the foggiest. But I guess it goes to show the importance of retracing your steps if you end up stuck down a dead end. That memory kit was only a year old, so it's currently wending its way back to Taiwan to be RMA'd - in the meantime I've borrowed a couple of spare sticks from a friend, and my system is back to its stable self. I did have one further strange issue - one of my array drives died while rebuilding parity, with a corrupt XFS filesystem on the emulated disk that just *would not* repair too. Hitting the check button in the GUI gave me an error: "update.php: missing csrf_token". Following troubleshooting steps for this I found elsewhere on the forum (safe mode, closing browser windows/tabs, etc) couldn't fix it, I couldn't fix it via the command line because it was an encrypted disk, and even resorting to a fresh Unraid install on another flash drive (copying only the disk config over from my main flash drive and nothing else, so parity would be carried over) wouldn't work. Very strange error. Only way to fix it was to new config the array and start rebuilding parity again from scratch, and restore that one disk's contents (again) from backups. Assuming no more drives fail, I'm home and dry. Phew.

Unfortunately yes. The only times I was able to boot normally and decrypt all drives was when all plugins were uninstalled, not just UD - but even then only sometimes, and even then the system would inevitably become unstable over time until it locked up completely. However! I think I've had a breakthrough. I booted up into a live Ubuntu instance off a USB stick after my last comment and had a look through all my disks via Disk Utility there. I could unlock a few of them using the correct passphrase I'd set in Unraid, but not most of them (which goes to my theory that something was causing the passphrase to be corrupted when being set). Disk Utility was able to successfully format all of them with encryption (XFS for HDDs, BTRFS for SSDs), and mount them afterwards too. I've just booted back into Unraid again, and now everything's mounting properly with encryption - and that's with all plugins still installed, for the first time since this whole saga began. I'm going to leave it overnight to see if the system remains stable this time, but things already feel back to their snappy and responsive best. I'm cautiously optimistic.

Update on this: I think I'm narrowing in on what's happened, and it's something to do with crypts and corrupted LUKS headers. I've now pretty much fully Ship of Theseus'd my server, and the behaviour continues to persist. I've now tried with 3 different motherboards - another X570 Taichi, and a Gigabyte X570 Aorus Pro (and flashed through multiple BIOS revisions for each). I've hooked my new Adaptec card up, and gone back to my old LSI card too. I've swapped drive cables in and out, I've changed the locations of devices in the PCIe slots, I've tried it without the NVME drives, I've tried it with just the SSDs, I've tried it with just HDDS, I've tried it with no HDDs at all and just SSDs. I've even tried with a completely fresh install of Unraid, on a completely new USB stick and a trial license. Nothing changes. Encrypted disks - BTRFS or XFS - cannot be opened at all now, and I cannot create new ones. And the culprit must be in the few things which have persisted between all these different changes: namely, the CPU, the RAM, or the disks themselves. I think it's the latter. If I take a completely fresh install of Unraid - and then install only Unassigned Devices (and Plus) - I can delete any existing disk partition fine. I can also then seemingly format any empty disk fine and create a new encrypted XFS or BTRFS filesystem. But if I try to mount any of those newly-formatted disks, this happens: From researching LUKS, my suspicions is that Unraid is essentially failing to correctly transmit the encryption passphrase to any of my disks - so of course, when it tries to use that same passphrase to mount the disk immediately after formatting, the two passphrases don't actually match. My only real guess for why this is happening is that the LUKS header partitions on all the drives have been corrupted... somehow? But it must be happening sometime during formatting and partitioning with the crypt process, and this is even happening with completely fresh installs of Unraid on multiple USB sticks, so it can't be down to system file corruption. It must be because of something being preserved on each disk between wipes. I'm aware I could just not use encryption and everything works fine, but - besides still preferring to use encryption if possible - the broader principle here is that I *really* want to figure out what the hell has happened here, for both my own sanity and in case this is a bug that affects anyone else who might find this thread in future.

Yes - I thought it might be RAM-related too at first, and one of the very first troubleshooting steps I took was to run memtest and also tune down the memory speed. On my previous board (Asus Prime X570-P) I’d been running these same sticks at full speed (3600) with the same CPU, which I know is faster than Unraid officially supports - but it hadn’t caused any issues, so stuck with it. I’m aware that Ryzen can in general be temperamental when it comes to Unraid, and I’m wondering if this is one of those unlucky cases where the hardware combination just doesn’t work. Too much I/O for a delicate storage controller, that kind of thing. I’m gonna try flashing the mobo BIOS back a revision or two (it’s been on the most revent version, 4.60, released August 2021, for all this) to see if maybe that helps, but it feels like clutching at straws tbh.

Update to this, in case anyone else finds themselves in the same situation: I'm thinking of exchanging this new mobo, because whatever's happening now feels like it must be hardware related. I've removed encryption from both pools but I'm still getting uncorrectable BTRFS errors appearing on them whenever I start loading them back up with data; meanwhile, I've found (from wiping a few more of the array drives as a test) that having more than the first four disks in the array encrypted causes the decryption errors to inevitably reoccur again (sporadically with 5-6 encrypted array drives, always with more than that). And, in general, the system just feels... deeply unstable. I've never had so many complete system lock-ups, so frequently, from doing things that my previous setup wouldn't even blink at. It's a shame, because I've seen plenty of people say that the X570 Taichi has served them well as an Unraid board - but as it's the only substantially different change to my system in terms of hardware, logically it seems more prudent to just get something else and see if it still happens, rather than spent more days chasing ghosts in software.

I'd prefer to keep it, but I suppose I could switch to encrypting individuals folders/files on an as-needed basis rather than full disk encryption, if this really is unavoidable. How time-consuming would it be to change for the array, though? It's nearly 50TB of data on there atm, which would probably take around a month to download again from my offsite backup, and I really want to avoid doing that if possible.

Damn - I thought this was fixed, but unfortunately it's still happening. Without any plugins installed, it doesn't happen every time, but it still happens maybe twice in three as I've been trying to re-establish my various configurations and settings, and stress-tested general system stability my starting/stopping the array. If I launch the array without any plugins installed directly after booting, it's generally fine - but the longer that the system is up, the less likely it is that restarting the array would be possible again without a full system restart. Same if plugins are reinstalled between array launches. I discovered that the Cache pool's BTRFS filesystem was corrupted with uncorrectable errors, so (with everything already backed up) I kept it simple by wiping the whole pool and starting fresh, like I'd already done with the Windows pool. I thought that maybe it was some kind of BTRFS-related process that was the culprit, since a balance would start on the Cache pool (whenever I could start the array properly), but the system would still become gradually unstable, correlating with the progress of the balance (which never finished). And I figured maybe something about that filesystem corruption had been the cause of the decryption errors - it was corrupted in such a way that the decrypting process itself was being destabilised somehow. (I have no idea if this mental model makes sense with how Unraid actually works, but this gelled with what I've been seeing - however, no filesystem errors have been found on the array, just the pool, so it still doesn't really make sense that a BTRFS problem would cause an XFS array to not decrypt too, I imagine...) I reduced each pool down to one drive each, then added one at a time to Cache until it was full (5 drives), waited for each balance to complete, then stopped the array and added the next one until all were done (5 drives). Then I added the second to the Windows pool. Sometimes drives weren't added properly - they were added without formatting to the pool, or without being encrypted, so I'd have to stop the array and try adding them again until Unraid actually recognised they needed to be formatted/encrypted correctly AND the array was entirely decrypted in general. Eventually I got there, but clearly something is going very wrong with how my Unraid is handling filesystems and drive interactions. And this is with both my existing copy and a completely new install on the flash drive (with the old config folder copied over minus the plugins), just in case it was some kind of file corruption with the system files that was the culprit.

I am - my Macbook is my only computer atm, until I get my Windows VM back up and running, and I deleted the plugins folder from the flash drive using Finder. Strange! I'm doing clean installs of all my old plugins and setting them up manually instead of copying any old files across, so fingers crossed however many of them were having issues won't from now on...

....I thought I'd narrowed it down to Unbalance after systematically deleting plugins one by one until something changed, but this now feels like something more fundamentally wrong than just the one plugin: 1) Reflashed my USB stick with my backup with all my old plugins, deleted the Unbalance plugin alone, started the array in maintenance mode, all OK 2) Re-downloaded Unbalance from community apps, seemingly installed OK, GUI accessible (although disk info not available because of maintenance mode ofc) 3) Disabled Unbalance server in its settings, then stopped the array and restarted in normal mode 4) Instantly get an alert that one of my cache drives is now missing, and the Unraid GUI otherwise becomes unresponsive 5) After a hard reset, deleted Unbalance again and tried booting into maintenance mode - no dice, back to disks not being decrypted I'm going to try deleting all plugins entirely off my flash drive - installed and removed history - to really test this, but I'm wondering if this is perhaps a hardware or BIOS issue, or something else beyond plugins which changes between safe and normal boot modes. A situation where Unraid is expecting or requesting some kind of data too slowly (or too quickly) and it's causing disk read issues across the system as it kind of "times out". Would explain the pattern of disks decrypting in sequence for only the first few and then stopping, in the same pattern, over and over again. Hmm. EDIT: Deleting the entire plugins folder has worked - I can start the array normally again. But I did notice something new. There were *four* cache pools when I booted. "Cache" and "Windows", as per usual, but also "._cache" and "._windows", both without any drives assigned and only one slot each. Where on earth did they come from? I deleted them entirely before booting and now it seems to be functioning normally, but this seems very odd to me... I'm guessing my efforts to swap disks between the two pools has caused it somehow, and now there are multiple plugins which think that there are two of each pool and it's causing everything to gum up?