trurl

removing a disk from the array has nothing to do with any plugin. There is a script some use when "shrinking the array", but the point of that script is to completely wipe the disk to be removed, which I assume is not what you want to do. Let us know when you are ready to remove the disk from the array. Lots of people besides me can help with that.

So is this some sort of hardware RAID controller in the computer?

Let me know if you need advice on how to do this. It isn't complicated, but if you don't know how I can probably tell you easier than you can search for it or figure it out.

Not suggesting that you do anything with its data. Leave its data on that disk. Just remove that disk from the array and build parity without it. Then the rest of your array is protected, and that disk can still be accessed as an Unassigned Device.

My question about backups isn't just about that disk. It is about your entire array that isn't reliable because of that one disk. Problems with that disk put your other disks at risk since if one of them does fail you may have trouble recovering its data because of the problems with that disk.

Or, just remove it from the array, rebuild parity without it, and if you do need any of its data, get it with the Unassigned Devices plugin.

You really should just forget about how to work around this, and instead take care of why it isn't working correctly. Anything else is compromising the rest of your array and its ability to recover if there is a problem with another disk. Suppose that disk you have been having problems with is going along just fine. Maybe the fact that you are trying to avoid using it actually helps. But then, another of your disks fails and needs to be rebuilt. For the rebuild, all disks must be read, including the disk you have been having problems with, in order to calculate the data for the failed disk. Now what happens if during that rebuild, that disk you have been having problems with disconnects again like it has been doing. Now what are you going to do? Do you have backups of anything important and irreplaceable?

The best way to do this is to let the server continue to use DHCP, but in the router, reserve the IP address you want for the server by its MAC address. That way everything on the network is managed at the router, and you won't have things using an IP already in use.

To summarize, there is no way to guarantee the disk won't be read while it is still part of the parity array, because the parity calculation must read all disks when necessary. The disk can be excluded for reading or writing all user shares by excluding it in Global Share Settings. Except, it still might be read as required by the parity calculation when reading other disks. And anyway, what did you think would happen with the disk during a parity check?

So do I, or actually, it is named "Public" A user share named "internal" is at /mnt/user/internal. Any top level folder named "internal" on cache, or on any array disk not excluded in Global Share Settings, is part of the "internal" user share. So, /mnt/cache/internal, /mnt/disk1/internal, /mnt/disk2/internal ... are all part of the user share named "internal". A user share named "public" is at /mnt/user/public. Any top level folder named "public" on cache, or on any array disk not excluded in Global Share Settings, is part of the "public" user share. So, /mnt/cache/public, /mnt/disk1/public, /mnt/disk2/public, ... are all part of the user share named "public". So, as you can see, there is no way to have a user share named "internal" that refers to /mnt/cache/public, /mnt/disk1/public, (skip /mnt/disk2/public), ... And anyway, I suspect that disk that you want to avoid accessing already contains several top level folders, and so already contains parts of several user shares. Each of those top level folders on that disk is part of the user share with the same name as that top level folder.

Sorry, not able to make any sense of that. Do you understand what I said here about how user shares work? Maybe lets break it down What does "them" refer to here? What is the name of this "public" share? What is the name of this "internal" share? It is the share name that defines a share, and any disk with a top level folder the same as that share name is part of that user share. So, you could have a "public" share and an "internal" share and you could exclude that disk from the "public" share, but these shares would be different shares in every other possible way since they would have different names and those names correspond to all top level folders on any disk by that name.

If it isn't the disk, it's the connection, cable, controller, or possibly power. Have you tried swapping the way it's connected with another disk to see if the problem goes to the other disk?

Then post new diagnostics.

If you don't exclude it from user shares in Global Share Settings, then it will still be read because all disks not excluded in Global Share Settings are included when reading user shares. It will still be read even if you exclude a disk for writing by specific apps (normally your apps would access user shares and not disks). It will still be read even if you exclude the disk for specific user shares. Because most of the settings for a specific user share just controls how new files are written to the user share. So if you exclude the disk for a specific user share, that will make it not choose that disk when writing new files to that user share. But the disk will still be read when reading that user share if the disk contains files for that user share. User Shares are simply the top level folders on cache and array. If a disk contains a top level folder for a user share, it is part of the user share, unless it is excluded from all user shares in Global Share Settings.

yes, unrelated to parity

If you just mean some way to make sure the disk isn't chosen for writing new files for user shares, just exclude it from all user shares in Global Share Settings. But that won't guarantee it won't be accessed if needed

And since you don't know why it doesn't work, how could you code around the problem?

This is way way below the level of "plugins", and anything you did would just be breaking the builtin parity protection.

The only way to guarantee it won't be used is to remove it. If one of the other disks becomes disabled, then Unraid will have to use that disk and all the others in order to emulate the disabled disk. If some data for one of the other disks can't be read, Unraid will have to use that disk and all the others in order to get the data that can't be read from that other disk then try to write it back to that other disk so it can be read in the future, or so it can be disabled if it can't be written. Fix whatever problem is making the disk become disabled. Have you run an extended SMART test on the disk?

If it is already disabled in the array, and one of your other disks really does fail, then the data for that failed disk is lost.

I don't think there was any misunderstanding, at least on my part, because I never thought it was parity. Maybe the misunderstanding is yours. Parity by itself doesn't protect anything. Parity requires all the other disks in order to recover the data for a failed, missing, or otherwise disabled disk. So, if that disk is already disabled, then parity can't help you if one of your other disks fails.

Why? If it isn't reliable then it makes parity worthless.

Next time it happens, go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

If the disk is fine then you should be able to fix whatever is causing it to become disabled. Or, why not remove it? If it is disabled and you only have single parity then you have no parity protection for the rest of the array.