Disk vs user share


Nem

Recommended Posts

My understanding of disk shares is that the contents of an entire disk gets shared out to the network, while a user share is a specific directory that gets shared (but can be spread out amongst multiple disks)

 

I want to set up user shares (as I don't want entire disks to be shared), but is it possible to force a user share to store data on only one specific disk? I ask because I want to keep all of my media on one hard drive, backups on another, so that if I needed to pull a drive from the machine I know exactly whats on there and that it contains everything I need.

 

I dont want to set up a disk share because sometimes there will be directories on a disk that are not meant to be shared for one reason or another.

 

How does one set this up?

Link to comment

My understanding of disk shares is that the contents of an entire disk gets shared out to the network, while a user share is a specific directory that gets shared (but can be spread out amongst multiple disks)

 

I want to set up user shares (as I don't want entire disks to be shared), but is it possible to force a user share to store data on only one specific disk? I ask because I want to keep all of my media on one hard drive, backups on another, so that if I needed to pull a drive from the machine I know exactly whats on there and that it contains everything I need.

 

I dont want to set up a disk share because sometimes there will be directories on a disk that are not meant to be shared for one reason or another.

 

How does one set this up?

In the settings for a User share you can specify what disks it is allowed to use.
Link to comment

As noted above, you can set which disk(s) a share will use by either setting the "Included" disks or the "Excluded" disks.    You don't need to use both of those -- just do whichever is most appropriate for your share.

 

e.g.  If you want a particular share to use all of your disks EXCEPT for a couple, just set those as "Excluded".    That way if you ever add another disk to your array, it will automatically be included in your share.

 

... but if you want a disk to ONLY use a specific disk (or disks), then just list those in the "Included" disks -- no other disks will then be included in the share.

 

Link to comment

There is one other thing you need to understand about user shares. They don't always obey these rules.

 

A user share results in a subdirectory with the name of the user share being created on each disk in the user share containing data. So if you have a user share called FISH configured on disk1 and disk2, each would have a folder called FISH. Now the tricky part is what happens if another disk, say disk4, also has a folder called FISH. Unless that disk is globally configured to not participate in any user shares, disk4 will become a somewhat reluctant member of the FISH user share. All its FISH files well show up with the user share. If a file on disk4 is updated via the user share, the update will be written back to disk4. New files well still tend to be written to disk1 or disk2, but even this is not assured. It depends on the split level and the existing subfolders present on disk4.

 

This condition most often happens when a user attempts to remove a disk from a user share. Changing the configuration to remove a disk does nothing with the folder on the removed disk or its files. Once they figure it out, they might try to copy the files form the disk share of the disk they are trying to remove to the user share. This is a deadly mistake. Called the "user share copy bug", copying from the disk share to the user share will result in unRaid trying to copy files over top of themselves. Normally an OS would detect this and give an error, but in this situation the OS is oblivious. And the attempt will result in each and every file in disk4's FISH folder getting truncated to 0 bytes, losing all their contents.

 

This is easy to avoid, but is something all users should understand to keep their data safe. Hope it makes sense.

 

BTW, one way to resolve this is to rename the FISH folder on disk4 to something else, like OLDFISH. UnRaid will create a new user share for OLDFISH automatically (may take any array stop and restart). You can then move the files from OLDFISH to FISH safely.

Link to comment

A user share results in a subdirectory with the name of the user share being created on each disk in the user share containing data. So if you have a user share called FISH configured on disk1 and disk2, each would have a folder called FISH. Now the tricky part is what happens if another disk, say disk4, also has a folder called FISH. Unless that disk is globally configured to not participate in any user shares, disk4 will become a somewhat reluctant member of the FISH user share. All its FISH files well show up with the user share. If a file on disk4 is updated via the user share, the update will be written back to disk4. New files well still tend to be written to disk1 or disk2, but even this is not assured. It depends on the split level and the existing subfolders present on disk4.

 

But surely this wouldn't happen if 1) no top level directories on any of the disks have the same name and 2) each share is explicitly told to use only a single disk?

 

This condition most often happens when a user attempts to remove a disk from a user share. Changing the configuration to remove a disk does nothing with the folder on the removed disk or its files. Once they figure it out, they might try to copy the files form the disk share of the disk they are trying to remove to the user share. This is a deadly mistake. Called the "user share copy bug", copying from the disk share to the user share will result in unRaid trying to copy files over top of themselves. Normally an OS would detect this and give an error, but in this situation the OS is oblivious. And the attempt will result in each and every file in disk4's FISH folder getting truncated to 0 bytes, losing all their contents.

 

Right now, I have 'enable disk shares' set to No, so even if I remove a disk, it shouldn't turn into a disk share anyway right? In other words, the files would not be visible for me to copy them to another location

 

Please correct me if I'm wrong because that sounds like a big bug, but with my intended setup I don't believe I'd ever run into this situation? For example:

Disk 1 contains a folder 'Media', then set as a user share (told explicitly to use only disk 1)

Disk 2 contains the folders 'Games', 'Backups', then set as different user shares (both told explicitly to use only disk 2)

 

So none of my top level directories share the same name. And if I were to remove a disk from a user share, well, my user shares are told to only use 1 disk, meaning the entire user share should be gone anyway.

 

Can you think of a way with this setup where I'd run into this bug?

Link to comment

So long as you are careful it should be fine.  Some things I've done that created issues were coping directories from one disk to another, using Midnight commander improperly (easy to do), or undoing previously created global user shares.  Just be careful with operations that could inadvertently create root level directories on a disk.

Link to comment

... But surely this wouldn't happen if 1) no top level directories on any of the disks have the same name and 2) each share is explicitly told to use only a single disk?

 

That's correct.  As long as you don't create the top-level directory UnRAID won't either if the share is limited to one disk.

 

 

... Please correct me if I'm wrong because that sounds like a big bug, but with my intended setup I don't believe I'd ever run into this situation? For example:

Disk 1 contains a folder 'Media', then set as a user share (told explicitly to use only disk 1)

Disk 2 contains the folders 'Games', 'Backups', then set as different user shares (both told explicitly to use only disk 2)

 

So none of my top level directories share the same name. And if I were to remove a disk from a user share, well, my user shares are told to only use 1 disk, meaning the entire user share should be gone anyway.

 

Can you think of a way with this setup where I'd run into this bug?

 

You should be fine.    One caveat:  r.e. "...  if I were to remove a disk from a user share ..."  ==>  If you simply change the share settings to remove the disk from the share, that does NOT actually delete the information ... i.e. the top-level folder and all of its data would still be on the disk.    So if you then create a new share with the same name on a different disk, THAT would result in the condition that was described earlier.    But other than that, if you do as you've outlined, you'll be fine.

 

Link to comment
  • 5 years later...

Since I am new to Unraid just to clarify my understanding.

If I have a user share called DATA and this user share is not Limited to any of the available disks. 
An let us assume the share folder was created on all available disks and contains data.

When I now change the setting of this user share DATA to exclude e.g. disk 3, the folder and the data will stay on disk3 but no additional data will be written to that share folder on disk3.

I assumed that the MOVER will move the data from the user share on disk3 to the other disks so that there will be no data in the user share folder DATA on disk3. 
But as I understand, I would have to move the existing data manually and erase the empty folder DATA on disk3.

Is my understanding correct?

Link to comment
13 minutes ago, matty2k said:

But as I understand, I would have to move the existing data manually and erase the empty folder DATA on disk3.

Is my understanding correct?

Yes. The share settings are only used by Unraid when deciding where to place a new file.

You could do this using the plugin Unbalance or manually (CLI, Midnight Commander, Krusader, etc).

 

If doing this manually, always move disk to disk, not disk to share or share to disk.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.