trurl

You can go ahead and format the data disks while it is building parity if you want.

Lots of call traces at the end of that syslog. Are you sure you got your memory configuration squared away (discussed in your other thread).

The way your docker related shares are currently setup is not the default. appdata and system shares would normally be cache-prefer so dockers wouldn't have performance impacted by slower parity and so docker wouldn't keep array disks spinning. You have appdata cache-only but some files are on the array, and system, where docker.img lives, is cache-no with all files on the array. Is this the way you had these shares setup before you replaced cache?

Are you writing to a disk in the parity array? 120 would be faster than expected for that. 120 might be about right for cache on GBit ethernet. Possibly you are seeing the effects of writing many small files since that will typically be slower than writing only large files. Don't know what you would consider "full speed", seems a pretty vague notion. Writing to the parity array is always slower than writing a single disk, though something more like 40-60 MB/s would be typical unless you enable turbo write. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

I never said "only". Disk1 contains some files for each of your shares. You can see how much of each disk each share uses by going to User Shares and clicking Compute... Go ahead and let parity rebuild complete on the original disk if it will. We will evaluate the next step as we see how things progress.

I would leave that until the array is stable.

When you create a new user share in the webUI, Unraid creates a top level folder named for the share on cache or array as needed and in accordance with the settings for that user share. But whether or not the top level folder is created that way, or simply by specifying a path that causes a top level folder to be created, all top level folders are part of a user share with the same name as that top level folder.

It is not so much that the user share is created. The user shares are just alternative views of the folders and files that have already been created.

Any top level folder on cache or array is automatically a user share, whether or not you actually created it as a user share in the webUI. In fact, people accidentally create user shares all the time by specifying a top level path somewhere, such as in docker mappings. And the user shares have the same names as those top level folders. If the top level folder exists on multiple disks, the share exists on multiple disks. Any user share you haven't configured has default settings, but since you copied the settings over, all you need is the actual top level folders themselves for the users shares to actually exist.

Keep working on it. There is no need for a VPN service. I can access my whole network with WireGuard through Unraid.

It's already having problems reading disk1 for the parity rebuild. Some other things I noticed, appdata, domains, system shares have files on the array. In fact, system is all on the bad disk1 which is probably why docker.img isn't mounting. You want these shares all on cache and stay on cache so they won't have performance impacted by slower parity, and so they won't keep array disks spinning since these files are always open. We can discuss what to do about that after your array is stable again. In fact, you might want to disable dockers and VMs and quit using your server at all until these disk issues are resolved.

Unraid is a custom stripped down version of slackware linux. Those commands should work

Once you have those shares then they will have the settings from their configuration files. But the shares themselves don't exist if there are no files for the shares. Those top level folders I mentioned are what is required for a share to actually exist.

Parity and disk1 both need to be replaced. Probably they didn't both go bad at the same time. Have you been ignoring these problems? Do you have Notifications setup to alert you by email or other agent as soon as a problem is detected? Don't let one problem become multiple problems and data loss. Do you know that in order to reliably rebuild every bit of a disk, whether parity or data, Unraid must be able to reliably read every bit of all other disks? Parity by itself cannot recover anything. And of course, currently parity is invalid anyway. Do you have another copy of anything important and irreplaceable? This should probably be the first priority before attempting to rebuild anything since you have 2 disks that may make rebuilding difficult.

User Shares span disks. You can limit which disks a User Share uses if you want, but by default all disks are allowed.

Recycle Bin relies on a feature of SMB, so unless you delete a file with network SMB protocol, Recycle Bin doesn't know about it.

Since you haven't replied with your diagnostics, I am going to give you some more information. A disabled disk and an unmounted (or unmountable) disk, are not at all the same thing. A disabled data disk is usually emulated from the parity calculation, and the emulated disk is usually mounted even though the disabled disk is no longer being used. But, parity is never mounted, whether or not it is disabled, because parity has no filesystem. Your ideas: Replacing one of the other disks won't fix disabled parity, and you can't even rebuild a replacement anyway because parity is disabled. Basically the same as 1. Closest to the right idea, but not clear there is anything wrong with the existing disk. Likely the solution is to rebuild parity, either to the same or a new disk, but can't say for sure without more information (your diagnostics) After you get parity enabled again you can consider replacing other drives. We will have to wait and see. PLEASE don't do anything without further advice.

Do you have an attached keyboard? Tell us about your hardware.

At least some of your suggestions are not good, so don't do anything without further advice!!! Go to Tools-diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

The user shares are simply the top level folders on cache and array disks. The share name is the same as that top level folder name. Any disk that contains a top level folder named for a share contains files for that share. This is how user shares work, whether you create them in the webUI or not. Any share you haven't made settings for will have default settings. So, if there isn't a top level folder on cache or array for a share, the share doesn't exist. Have you started copying the share yet? I assume its doing parity sync, which is what it has to do to build parity initially. Probably, XFS has some filesystem overhead, more for larger disks.

You must be misinterpreting this. Take a look at the first timestamp in syslogs and you will see it corresponds to reboot time. They definitely do reset on reboot but that won't fix filling them up again of course.

It is the correct place in Settings, but that screenshot shows docker service enabled.

Here is what he was referring to: My reasoning here is that any disconnects due to USB (whatever number) is going to result in out-of-sync array requiring frequent rebuilds. Plus the bottleneck of putting multiple disks on one port, potentially defeating parallel access of parity operations.

If you have docker.img on cache as recommended then it will be open even if no containers are running. You have to disable the docker service itself in Settings - Docker.

Your link didn't work. We prefer attachments instead of links to external sites anyway. Now that you have been approved you should be able to attach the image to your NEXT post.