Unraid 7.3.2

I've got a Fix Common Problems notices that I'm not too sure what to make of. But as a result one of my drives resulted in the following. I'll quote the notices as well.

udma crc error count is 7

Errors have been found with your server (Atlus).

Description

Investigate at Settings / User Utilities / Fix Common Problems

• Out Of Memory errors detected on your server The plugin open.files.plg is not known to Community Applications and is possibly incompatible with your server Share zfsappdata set to use pool zfscache, but files / folders exist on the cache pool

Errors have been found with your server (Atlus).

Description

Investigate at Settings / User Utilities / Fix Common Problems

• disk8 (ST12000VN0008-2PH103_ZS806L0Q) is disabled disk8 (ST12000VN0008-2PH103_ZS806L0Q) has read errors Out Of Memory errors detected on your server The plugin open.files.plg is not known to Community Applications and is possibly incompatible with your server Share zfsappdata set to use pool zfscache, but files / folders exist on the cache pool

I looked this AM and disk8 was disabled and everything else was working. I decided to do a reboot and these notices popped up:

Unraid Disk 8 SMART health [199]

Warning [ATLUS] - udma crc error count is 9

Description

ST12000VN0008-2PH103_ZS806L0Q (sdf)

Priority

warning

Unraid array errors

Notice [ATLUS] - array turned good

Description

Array has 0 disks with read errors

Priority

normal

If everything is now turned good, and the memory issue no longer seems to exist, what's the procedure to get disk8 working again?

atlus-diagnostics-20260815-1348.zip

Edited Saturday at 07:49 PM3 days by updatenil
Diagnostics included

open.files.plg - 2025.12.03  (Unknown to Community Applications)

You should remove that and install a newer version if there is one.

zfsappdata does have some files on cache. Nothing can move open files. Simplest thing is to disable Docker in Settings so those could be moved, depending on settings for that share. Post a screenshot of the settings for your zfsappdata share.

UDMA CRC errors are connection problems, not disk problems. Just acknowledge the current count by clicking on the SMART (👎) warning on the DASHBOARD and it will warn again if it increases.

syslog-previous shows the connection problem with disk8 that disabled it.

Emulated disk8 is mounted so should be OK to rebuild on top after you have fixed its connection.

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Also, looks like you may have lost+found share on disks 12,13 from previous check filesystem repair. Have you looked at those?

@trurl Thank you for your reply.

I'll include the screenshot for zfsappdata share.

When I have some time I'll carefully open up the server and check all the connections to the drives. I was never good at cable management so maybe I'll let the side panel of my PC stay loose instead of jamming everything in.

I haven't looked at what's in lost+found so I'll check it out. If nothing in there appears important can I safely delete the contents?

That share is configured to move files from array to zfscache. But it has no files on the array. Set it to Secondary storage:cache then you should be able to set Mover action to cache->Zfscache. As mentioned

31 minutes ago, trurl said:

Nothing can move open files. Simplest thing is to disable Docker in Settings

Then you can run Mover to get those moved from cache to Zfscache.

22 minutes ago, updatenil said:

I haven't looked at what's in lost+found so I'll check it out. If nothing in there appears important can I safely delete the contents?

The problem with lost+found is that is where repair puts files that it can't figure out, so they will often have random file and folder names. Linux 'file' command can be used to try to figure out what type of data a file contains so you can try to open it in an appropriate application and see if you can identify it. If there is a lot to go through, probably easier to restore them from backup if you can figure out what might be missing. Disks 12,13 currently have files from 2 shares

a------l                          shareUseCache="no"      # Share exists on disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8, disk9, disk10, disk11, disk12, disk13, disk14
j----------e                      shareUseCache="yes"     # Share exists on disk1, disk2, disk3, disk4, disk5, disk6, disk7, disk8, disk9, disk10, disk11, disk12, disk13, disk14

plus there were 2 other shares that have no files currently

b--------------n                  shareUseCache="no"      # Share does not exist
p--x                              shareUseCache="prefer"  # Share does not exist

31 minutes ago, updatenil said:

When I have some time I'll carefully open up the server and check all the connections to the drives.

Since you have dual parity you still have redundancy without disk8. But you should still find time soon to take care of this. If your cabling is a mess you may get problems with other disks.

Some tips on cabling. Don't bundle data cables. All cables, data and power, must sit squarely and firmly on the connection with no tension on the cable that might pull it loose. Also, power connections can cause similar problems. Ideally, no more than 4 disks per PSU cable, even if you use splitters. If you must use splitters, MOLEX-SATA splitters are better than SATA-SATA power splitters. If you don't have enough SATA cables from the PSU, disks can be connected to MOLEX cable with MOLEX-SATA connector.