Im pretty sure there is currently no proper way to do this so i guess you can consider this a feature request. 

Example Scenario: You create a new share and forget to setup disk assignment, or you have an empty share and you want to move it to a different disk.

In ether case a new folder will be created on the assigned disk(s) and an empty folder will be left on the previous disk(s) and as far as i can tell there is not proper way to remove these empty folders. 

The only way i know of to remove this empty folder is to manually delete it from the disk then run a parity check to correct the error that causes. This is far from an ideal solution. It would be nice if unraid had the ability to clean up empty share folders in a way that does not break parity.

 

If there is already way to do this then i apologies but i could not find anything related to this on the forum or google.

Parity is maintained during deletions so no parity correction needs to be done. Not sure why you would think so. Do you think you have to rebuild parity when you delete a file? 

 

Delete is just another write operation at the disk level, and all writes maintain parity when they happen.

 

A common error people sometimes make is thinking they can format a disk then recover the data from parity. But formatting is just another write operation, and after formatting parity agrees that the filesystem is empty.

 

At the disk level everything except a simple read is a write, which updates parity realtime.

I think you misunderstand me. Im talking about deleting a file from disk directly. e.g. deleting a file form /mnt/disk1 Im not talking about deleting a file from a share via something like SMB or  /mnt/user/<some share>

 

Deleting anything from disk directly in this way bypasses parity completely which results in invalid parity bits for the modified portion of the drive. 

I can also confirm this because i have done this in the past. Just yesterday i deleted an empty share folder from a disk that was not assigned to said share then ran a parity check. 7 hours later the check completed and corrected 1 error.

 

The message "Share is outside the list of designated disks" appears when a share exists on a disk, but the include/exclude rules tell not to use the disk for that share.

 

Two options:

1. Adjust your include/exclude rules so the disk becomes part of the list allowed for the share
2. Use CLI and midnight commander (mc) and move the folder (=share) from the non-participating disk (/mnt/diskX) to a participating disk (/mnt/diskY). Or simply delete the folder from the disk if not used.

 

32 minutes ago, brandon3055 said:

I think you misunderstand me. Im talking about deleting a file from disk directly. e.g. deleting a file form /mnt/disk1 Im not talking about deleting a file from a share via something like SMB or  /mnt/user/<some share>

 

Deleting anything from disk directly in this way bypasses parity completely which results in invalid parity bits for the modified portion of the drive. 

I can also confirm this because i have done this in the past. Just yesterday i deleted an empty share folder from a disk that was not assigned to said share then ran a parity check. 7 hours later the check completed and corrected 1 error.

 

You must have had some other problem to cause the parity error as doing operations on /mnt/disk1 updates parity.

1 hour ago, remotevisitor said:

 

You must have had some other problem to cause the parity error as doing operations on /mnt/disk1 updates parity.

Interesting... Everything i have read on this topic says you should never modify content on disk directly as it can cause corruption. I assumed that meant parity related corruption. 

When the array is operational, any change to a share or disk translates into a real-time update of the parity.

 

46 minutes ago, brandon3055 said:

Everything i have read on this topic says you should never modify content on disk directly as it can cause corruption. I assumed that meant parity related corruption. 

This happens if you change content using the disk device, e.g., run a filesystem check on /dev/sdb1 instead of using the md device

 

2 hours ago, brandon3055 said:

Interesting... Everything i have read on this topic says you should never modify content on disk directly as it can cause corruption. I assumed that meant parity related corruption. 

 

Be interesting to know where you have been reading.

Here is one example 

I know i have seen others but cannot find them now.

31 minutes ago, brandon3055 said:

I know i have seen others but cannot find them now.

 

I don't really agree with the text as formulated in your linked thread. But the last sentence is important: "You either do one or the other, if you do both you are going to have a bad time."

 

You can make changes to /mnt/disk<x>/... without problems.

You can make changes to /mnt/user/... without problems.

 

But it is dangerous to try to copy or move data where source is /mnt/user/ and destination is /mnt/diskX/ or the reverse. Because the copy program will not properly see that the two different paths might be the same physical disk location. So you can open /mnt/disk1/documents/my_important_document.txt and write to /mnt/user/documents/my_important_document.txt and end up with a zero-byte file.

 

So the two ground rules:

- avoid using both /mnt/diskX/... and /mnt/user/... in the same copy command. This must be avoided both when accessing locally on the unRAID machine, or when performing copy remotely over SMB shares. And this is the reason why the recommendation is not not publish /etc/diskX/ shares - if all external machines can see are /mnt/user/... shares, then external machines can't accidentally perform any such move attempts.

- avoid directly writing to raw disks (/dev/sdX) since such write operations will happen one step below the parity logic. So you can't repair a file system by specifying /dev/sdc because that will invalidate the parity. But you can repair a file system by specifying /dev/md3, because the parity logic will see all disk writes performed during the file system repair and will update parity on-the-fly.

And even if you do make the mistake of mixing user shares and disks when moving / copying, parity will be maintained. Which means there would be no need to rebuild parity, but no way to use parity to recover from this mistake.

 

So, the text you linked has absolutely nothing to do with parity and whether or not it would be in sync.