itimpi

I have a remote share that is automounted by UD when the system first boots and the array is started. However if I Stop the array this remote share is unmounted by UD and I have to manually mount it again myself if I want to continue using it. Is there any way I can tell UD that I do NOT want this share marked as being auto-mounted actually being unmounted when the array is stopped (or at least it should be auto-mounted again after the Stop completes)? In principle I guess the same question can be applied to local drives managed by UD. Is this expected behaviour or a bug? If expected then I was thinking of something along the lines of the PASS THRU toggle that the user can set might be a good idea.

It just means pre-fill the assignments with the current drives to save you some effort and reduce the chance of you making an error. Until the array is started the assignments are not committed so you can make any changes you like at this point.

You cannot have the -—mconvert=raid1 option with only a single device in the pool

As was mentioned you can run any CLI app under Screen to avoid needing to keep a session open and let it continue running in the background.

This is included as standard in Unraid

Yes, because the Season 1 folder would be level 3 so cannot exist on more than one drive with Split Level set to 2.

Yes as the ‘Mom’ folder is allowed to exist on multiple drives at Split Level 2 so files directly under that can exist on any drive.

If a drive that should be in the array subsequently appears under Unassigned Devices then it means that the drive dropped offline for some reason and then came back online with a different device identifier. Unraid is not hot-swap aware so does not handle this happening.

Yes. The first 2 levels can be split across drives, but not the 3rd level (the Season folder). Do you actually have a belief this is not what is happening?

Handling of ‘unmountable’ disks is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the Unraid GUI. Have you run a file system check on the drive? Was the drive showing as unmountable before the rebuild (since a rebuild does not clear ‘unmountable’ state`).

This the array operation. The fact it is a "Read Check" implies that you have at least as many drives marked as disabled as you have parity drives. Is this actually the case?

That share had Split Level of 1, so once a folder is created on a drive all content for that folder (and sub-folders) is forced to the drive where the folder is first created. I suspect you need a less restrictive Split Level, but without knowing the paths of files involved this is just a guess

Could you please give us the link to the wiki entry you used as the steps you mentioned are not sufficient to achieve what you wanted so it may need correcting.

Only if you do it over the network where the User Shares are then seen as different mount points. If you do it locally within the server then Linux (which is not aware of User Shares) thinks both source and destination are on the same mount point so it uses a rename rather than a copy/delete operation which leaves the file on the same drive.

This sounds like a Dolphin issue rather that an Unraid one To help with working out why this might be happening I suggest you post: Your system's diagnostics zip file obtained via Tools Diagnostics and give a time where you see this issue to help identifying a relevant part The Run command used to start the Dolphin container as mentioned here so we can check any drive mappings.

Not quite /mnt/cache/appdata is the appdata folder on the cache drive, while /mnt/user/appdata is the amalgamation of appdata folders on all drives (including the cache). If you only have an appdata folder on the cache drive they end up effectively being the same.

Parity1 and Parity2 use different calculations so they are not interchangeable. It is perfectly valid to run with Parity2 and no parity1 although some people find it annoying. If you want to switch parity2 to become parity1 then you can rebuild parity1 by doing the following: Stop array Unassign Parity2 Start Array. This is to let Unraid 'forget' the parity2 assignment. Not sure this step is actually necessary but it will do no harm. Stop array Assign the drive to parity1 Start array to build the parity1 contents Note that if you go this route your array will be unprotected until the build of parity1 is completed.

As far as I know Limetech update any packages when they make new Unraid releases as long as they are compatible with the underlying Linux kernel version shipping with that Unraid release. What you will not see is security fixes applied retroactively on top of an existing Unraid release. If there are some that you specifically think need updating it might be worth mentioning them.

Thanks for the feedback - will have to see how it pans out when trying to detect the various conditions. I cannot find any easy way to add buttons to the Main tab so am trying to find a way to work within the current behaviour.

It looks as if the way to ac It looks as if the way to achieve what you want will be by using Pause (which re-enables the Stop button) before trying the Stop button. Would this be an acceptable way of operating for you? I will need to explain this in the Help text associated with the configuration option I have added to enable users to restart array operations. This raises another question - if a Paused array operation is later restarted should it automatically be put back into a Paused State as part of the restart process? This would mean the user having to use the Resume button in such a case to continue with completing the operation. I feel that might be a good idea but welcome feedback but I am not sure. It could also be made a plugin configuration item depending on the feedback I get.

If you get anything useful then please provide the details and I can look into adding it to the information provided here in the online documentation that can be accessed via the 'Manual' link at the bottom of the Unraid GUI.

As long as drives are completely zeroed they will not affect either parity drive. Size is not a factor as Unraid assumes that any space beyond the physical size an array drive can be treated as if it were zero filled.

If you have to do this anyway why not simply do it before using the Stop or Reboot buttons. I am not sure how this plugin could help you in such a case as one of the pre-conditions of doing the restart of the array operation is that a clean shutdown of the array has happened.

You use the Shutdown or Reboot buttons. This automatically issues a shutdown command for the array (which my plugin can catch). At the moment Unraid will not let you stop the array if you have an array operation running - you have to first cancel the array operation before the Stop button is active. I am not sure if this behaviour can easily be changed in any way. If it can then the plugin will be able to exploit that but at the moment I have not worked how to change this behaviour although I do intend to continue looking at it. It is worth noting that if the Stop button was going to cleanly stop the array then the Reboot/Shutdown buttons would do so as well as they first issue the same command sequence that pressing the Stop button initiates. Since the restart can only happen if the array shutdown was a tidy one anything that would stop this being the case would also stop the restart of the array operation from happening.

It appears that this is not a valid Use Case as it is not (currently anyway) possible to Stop the array with an array operation running. On thinking about it makes some sense as why would you want to stop/restart the array without a reboot if you were not planning to make a change (which would invalidate a restart of the array operation anyway) However maybe someone can up with a good reason and if so I may look further into if this can be made to work. I have this Use Case up and running on my test server. I see the main reason to use it as the scenario where a server is not left powered on 24x7.