trurl

See if you can boot memtest86 on your server.

You only posted the syslog. Do you have the diagnostics?

Have you tried the built-in File Manager?

Post new diagnostics

User shares are simply the combined top level folders on array and pools. If a top level folder is created on array or pools, it is automatically part of a user share named for the folder. If a top level folder on array or pools doesn't exist, it isn't a user share, even though there may be a .cfg file in config/shares. If an array disks is unmountable, for example, and it was the only place that had a top level folder for a user share, the user share doesn't exist. If check filesystem fixes the filesystem so the folder exists again, its .cfg file applies to the share again. So the webUI isn't the only way to create (or delete) user shares.

See if you can reproduce in SAFE mode.

go file is not the recommended way to do these things anyway. Unassigned Devices plugin will mount remote shares. User Scripts plugin is where you should be putting other startup code.

Or maybe something you are doing with these "unknown" plugins (I know what they are) NerdTools.plg - 2024.02.17 (Unknown to Community Applications) un-get.plg - 2024.11.22 (Unknown to Community Applications)

Looks like this might be the result of your go file. Can you reproduce with the stock go file?

Still wondering if the error message is accurate. That looks like Directory Opus, which I also use but don't experience this problem with it. Have you tried New Permissions on that share?

According to many diagnostics I have examined, many users have lots of these 'orphaned' share .cfg files and probably have had for a long time. Haven't noticed these particular errors in their logs though. For example: https://forums.unraid.net/topic/198151-unraid-share-sub-directory-not-showing-contents-on-disks-include-in-share/#findComment-1616929 Not claiming it doesn't happen perhaps in combination with other things in your setup, but it doesn't seem to be common.

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/array-health-and-maintenance/#reset-the-array-configuration

Tools - New Config - Retain All - Apply. In Array Devices, your disks will be assigned as before. Assign the repaired disk as disk9. Start the array to begin Parity Sync.

Attach Diagnostics ZIP to your NEXT post in this thread.

Maintenance mode is not even read-only. None of the drives are mounted, so no access to their filesystems are possible. No read and no write. Rebuild has nothing to do with filesystems though. It is working at a lower level.

Didn't see anything in the logs that explain crash. SAFE mode just keeps plugins from loading. I mean Maintenance mode. It's a checkbox next to the START button.

If you New Config the repaired disk and rebuild parity, there would be less to restore from backup. You could just delete the lost+found folder

You can click on SMART (👎) warning after you decide what to do about it and then Acknowledge it from the popup. It will warn again if any monitored attributes increase. UDMA_CRC_Error_Count is logged by the drive firmware when it receives inconsistent data (checksum). This is a problem communicating with the drive, often just a loose or maybe bad cable. It often won't cause I/O error since the data is resent. And I/O error often won't cause CRC error since the drive doesn't receive any data to checksum. I usually just Acknowledge the occassional CRC error. If it is increasing frequently you need to check connections. Disk4 has a lot of these, but maybe they aren't occurring now. It also has a single Runtime_Bad_Block, probably OK for now. Disk7 has a single Reported_Uncorrect, probably OK for now. Neither drive has had any self-tests. You might consider running Extended self-test on both. Disk9 is just disabled and will remain so until rebuilt, or New Config resets that.

Only on the WD drives.

Did you also

Ideally, Docker/VM related shares - appdata, domains, system - would have all files on cache or other pool with nothing on the array, so Docker/VM will perform better, and so array disks can spin down since these files are always open. Or in your case, so array disks won't be busy during parity check or rebuild.

I guess you could rebuild it anyway then see if UFS Explorer could recover anything from it.