itimpi

You need to enable SSH under Settings->Management Access. At the moment it appears to be set to No.

The disk will stay disabled until you successfully rebuild it. The fact that the emulated disk1 appears to now be mounting fine is a good sign, but you need to sort out the disk connection issues before attempting a rebuild or you are likely to get a write error during the rebuild and the disk promptly disabled again as a result.

Even 1 error is too many

The GUI source is already publicly available on gitHub as is the documentation although Limetech still exercise an element of control in that changes have to be submitted via Pull requests to gitHub.

I personally have no experience of using that script. Was that script run at a point when you were getting a report that the free space was low? That would be needed in case a particular container is writing working file internally to the image and later deleting them.

It is definitely a UD related issue as core Unraid provides no support for HFS+. What confuses me is that you say it works for some HFS+ formatted drives and not others I wonder what the difference is.

You do not have to have a pool called 'cache' - this is optional as you can give a pool any name you like. That does not stop a pool being used as the 'cache' for a User Share as you set that up at the User Share level and can select any pool you have to provide the cache functionality for that particular share. Different User Shares can potentially use different pools to act as their 'cache' although that is rarely the way Users do it.

Not as far as I know. Having said that since a parity check is a relatively infrequent operation and can badly degrade overall performance while it is running maybe the 'warning' level is deemed appropriate. If you are using the Parity Check Tuning plugin to help manage parity checks better then I have reduced all the similar warnings it generates to only be at 'normal' priority.

There is currently a requirement that there is at least 1 drive in the main Unraid array. If you are going to create a ZFS pool as your main storage and store no data on the main array then you can use any old flash drive (of the sort used to boot Unraid) to satisfy this requirement. In a future Unraid release this requirement is expected to disappear.

You are getting continual resets on ata4 which I assume is the disk1 you are intending to rebuild. You can see this if you look at the syslog (accessible via one of the icons at the top right of the GUI. This could be a cabling issue to the drive (power or SATA) or it could be the drive itself going bad. Do not see much point in continuing the rebuild until you have resolved this issue.

You should post new diagnostics so we can check the state of things.

Restart in normal mode and hopefully the disk will now mount OK. You should check to see if there is a lost+found folder on the drive as that is where the repair process puts files for which it could not find the directory entry to give it the correct name. Not having that folder is a good sign that the repair process recovered everything cleanly.

the term cache is often used in two different contexts with Unraid. You can (optionally) have a pool called ‘cache’. It may or may not be used for ‘cache’ functionality. For historical reasons the default name for the first pool is ‘cache’. Personally I think there is a good case for selecting a different default name in the future. The actual cache functionality is set up at the User Share level and is not necessarily linked to the pool called ‘cache’. It can be used with any pool that is the Primary storage for a User Share

It will prefill the option field with -n but you can remove that or nothing gets done. If it subsequently prompts for -L you need to add that,

You should download the zip file for the release and extract ALL the bz* type file overwriting those on the flash drive as described here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

Are you sure it is not the directory without the 'l' that exists as the screenshot suggested.

Disk1 in the main array (it should be showing unmountable).

I did suggest you ran the repair on the emulated drive (before assigning a new disk1) 🙂 Does Unraid say it is going to rebuild disk1 (which is what I would expect)? If so starting the array will start the rebuild. However all the rebuild process does is make the rebuilt disk match the emulated one so it does not fix file corruption. You can attempt to fix the corruption later if you want.

If the check/repair I pointed you at works without issue then the data on disk1 will ‘reappear’.

At the moment it looks like disk1 is the problem drive and is being emulated but is showing as unmountable (due to file system corruption)? The correct handling of unmountable disks is described here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. You should run the check/repair on the emulated drive before attempting a rebuild as the rebuild process would just replicate the corruption onto the replacement drive. Keep the ‘failed’ drive intact as it may offer additional recovery options if the repair fails. Are you sure the drive in question has actually failed? Often a drive gets disabled due to external factors rather than the drive being faulty? If you are not sure you can try running an extended SMART test on the drive. If it passes error free the drive is probably OK.

We need diagnostics that show the problem to have any chance of diagnosing why. If you also get the server crashing then you can enable the syslog server to get logs that survive a crash so we can then see what lead up to the crash.

I have had issues in the past where particular drives would tend to drop out and in most cases I have tracked it down to the power cabling to the drive not being ideal.

No - if downgrading does not fix it then it is almost certainly a hardware issue. If you think all the drives are on the HBA check it is properly seated in the motherboard, and no cabling to it has come loose.

The. Diagnostics seem to show an automatic parity check starting when the array is started due to an unclean shutdown, followed by you logging in and cancelling the check. No sign of a check getting anywhere near completing so I am not quite sure what you are referring to in your description.

In safe mode no plugins are loaded which suggest one of your plugins is causing an issue. It is probably worth booting in safe mode and creating new diagnostics at that point to see if we can spot something.