Energen

I rebooted the server and had the same problem upon start, drive missing. I shut down the server (power off) and turned it back on and drive is online.

@JorgeB So things have been running fine for the last week, until today. Same problem occurred out of nowhere. Disk Location: nvme0n1 Alert - Device failureSamsung SSD 990 PRO with Heatsink 2TB Jun 18 18:49:04 UNRAID kernel: I/O error, dev loop3, sector 76160 op 0x0:(READ) flags 0x1000 phys_seg 4 prio class 2 Jun 18 18:49:04 UNRAID kernel: BTRFS error (device loop3): bdev /dev/loop3 errs: wr 0, rd 1, flush 0, corrupt 0, gen 0 I find it a little concerning/coincidental that there have been a few threads recently about nvme cache drive problems all occurring around the same time out of nowhere. If the drive were failing I would expect it to be failing daily and not run fine for a week without issue. It's as if something on the system is causing a breakdown. I have 2 identical nvme's installed at the same time, granted used for different purposes and the cache drive get used with more activity, but this is very strange. I ran SATA SSD cache drives for years without problems, and now the nvme for ~2 years without a problem, not sure what's going on. Is it the drive or something in Unraid. unraid-diagnostics-20260618-1848.zip

The only change from what's currently there is the pcie_port_pm=off Original: [quote] label Unraid OS menu default kernel /bzimage append initrd=/bzroot nvme_core.default_ps_max_latency_us=0 pcie_aspm=off [/quote] I'll give this a go and see what happens. Thanks! It's very peculiar that this has only started, and that's it's occurred a week apart. If the SSD was dying I would expect a much more consistent problem.

I didn't want to hijack @Elmojo 's thread about his failing cache drive, https://forums.unraid.net/topic/199306-cache-pool-errors-failing-drive-or/ But it seems I have a very similar problem, at a similar time, with a similar nvme ssd - a Samsung 990 Pro. Passes all tests and doesn't directly report any read / crc / anything else errors. Last week I came back from vacation and Unraid reported the drive was offline - I forget the wording as I thought it was just a glitch and rebooted the server - to find my cache gone. Rebooted a few times, checked a couple things, nothing changed. Server was kept off for a couple days while I ordered a nvme to usb dock to just check the drive - because isn't that what we'd all do? :D Disk seemed good, went back into the server and booted up - everything worked. Hmm.. ok weird, right? Fast forward until tonight, about an hour ago the cache share disappeared again - no messages from Unraid other than console logs such as: UNRAID kernel: nvme nvme1: I/O tag 735 (c2df) opcode 0x2 (I/O Cmd) QID 14 timeout, aborting req_op:READ(0) size:131072 UNRAID kernel: I/O error, dev nvme1n1, sector 1954447249 op 0x1:(WRITE) flags 0x29800 phys_seg 1 prio class 2 UNRAID kernel: I/O error, dev loop3, sector 75840 op 0x0:(READ) flags 0x1000 phys_seg 4 prio class 2 UNRAID kernel: BTRFS error (device loop3): bdev /dev/loop3 errs: wr 0, rd 7, flush 0, corrupt 0, gen 0 UNRAID emhttpd: device /dev/nvme1n1 has size zero This time I rebooted, and everything is fine again. Preemptively I'm going to start backing up the cache drive to the array like Elmojo is doing, but does this all point to a failing ssd or should I be looking at some other cause? Diagnostic file doesn't have anything of interest relating to this drive other than the logs above, and I've been running 7.2.4 for quite some time so it's not a recent upgrade issue.

One of my HGST drives for comparison -- 66588 (7y, 7m, 3d, 12h)

Assuming that your NAS is full and you can't add any new empty drives you're only real option is to move as much data as you can off 1 or 2 of your existing drives onto the other drives, consolodate to as few existing drives that you can. Then add as many new drives that you can replacing the ones you've emptied off. Then repeat that process with the remaining 2TB drives, moving that data to the new empty drives. It's a bit of a hassle, but it's just about the only way to do it. You can use the unblance plugin to simplify the process a little bit to consolodate data.

You need to move the downloaded files to a new location before deleting them from the seedbox. Think of the settings -- receive only --- you delete a file from the seedbox and that change is received also. You should think of Syncthing as an intermediate handler and not as a final destination. Download to a temporary location and then move the files out to their permanent residence. This can be handled by Sonarr/Radarr, not sure about Plex.

Apologies for the late response. My setup is actually reverse to yours. I have Unraid as the host for the UPS, i.e. the UPS is connected by USB to Unraid. In the grand scheme of things my Unraid server is the more important piece of equipment to handle in a power outage. Then on my Windows machine I have apcusbd running as the slave, and it gets it's power outage information from Unraid. I imagine though that your setup should be able to be accomplished, you would just have to figure out which combination of settings on Unraid works. In the UPS settings of Unraid you may have to play with the UPS cable and/or UPS type options to figure out how to connect to the Windows apcusbd. It seems that it's probably easier to do it my way though.

Unraid keeps giving me a red warning that Disk 6 has read errors ---- 4, to be precise. Jul 5 01:38:32 UNRAID kernel: md: disk6 read error, sector=1952415512 Jul 5 01:38:32 UNRAID kernel: md: disk6 read error, sector=1952415520 Jul 5 01:38:32 UNRAID kernel: md: disk6 read error, sector=1952415528 Jul 5 01:38:32 UNRAID kernel: md: disk6 read error, sector=1952415536 Regularly scheduled parity checks end ok, no issues there. No other known issues with data on the drive and all SMART tests succeed. Is this warning to be believed? Going back to see other read error threads there's been a lot of talk of the multi zone error rates and things of that nature when suggesting to replace disks, well here's Disk 6's stats: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 270 3 Spin_Up_Time POS--K 187 184 021 - 5650 4 Start_Stop_Count -O--CK 100 100 000 - 59 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 100 253 000 - 0 9 Power_On_Hours -O--CK 053 053 000 - 34890 10 Spin_Retry_Count -O--CK 100 253 000 - 0 11 Calibration_Retry_Count -O--CK 100 253 000 - 0 12 Power_Cycle_Count -O--CK 100 100 000 - 56 192 Power-Off_Retract_Count -O--CK 200 200 000 - 36 193 Load_Cycle_Count -O--CK 196 196 000 - 14032 194 Temperature_Celsius -O---K 122 103 000 - 28 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 200 000 - 0 198 Offline_Uncorrectable ----CK 100 253 000 - 0 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 47 In comparison here is Disk 7's stats which would appear to be a more likely candidate for replacement, yet prompt no issues. ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 12655 3 Spin_Up_Time POS--K 198 182 021 - 7083 4 Start_Stop_Count -O--CK 094 094 000 - 6057 5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0 7 Seek_Error_Rate -OSR-K 199 199 000 - 71 9 Power_On_Hours -O--CK 046 046 000 - 39522 10 Spin_Retry_Count -O--CK 100 100 000 - 0 11 Calibration_Retry_Count -O--CK 100 100 000 - 0 12 Power_Cycle_Count -O--CK 100 100 000 - 116 192 Power-Off_Retract_Count -O--CK 200 200 000 - 56 193 Load_Cycle_Count -O--CK 165 165 000 - 105243 194 Temperature_Celsius -O---K 122 107 000 - 30 196 Reallocated_Event_Count -O--CK 200 200 000 - 0 197 Current_Pending_Sector -O--CK 200 200 000 - 0 198 Offline_Uncorrectable ----CK 200 200 000 - 0 199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0 200 Multi_Zone_Error_Rate ---R-- 191 191 000 - 3398 Should disk6 in fact be replaced or is 4 sectors not enough of an issue to worry about and Unraid is just being super sensitive? I'm certainly sure that over the years I've ran drives for a multitude of years with read errors and such and never knew about them and the computer just blissfully kept on chugging along with no problem. Thanks for the info.

How about from the Go file? Is it a passphrase? You could try echo -n "key" > /root/keyfile and see if that works.

How is the keyfile getting to /root? There may be an issue there. I had endless problems using encryption and keyfiles. Decided it wasn't worth the hassle.

Easiest way would be to just name the new docker the same as the old docker... so that the appdata folder is named the same. Nothing else would change in that case. Or you could use a script such as the one linked in my signature to back up essential plex data which you could then use to restore in the new appdata folder..

find * -maxdepth 9999 -mtime +5 -exec rm -vf {} \; -exec /bin/echo {} \; | wc -l | { read count; echo "Done. $count files deleted."; } Grabbed this syntax from a thread on stackoverflow, works good.

Does everyone's CPU max out while scanning for photos? This thing was maxing out all my cores/threads until I pinned it down to 2/2 ..