It appears that unRAID assumes that every directory appearing at the root level of any disk (including the cache drive), should be a user share.

 

This is detectable in the syslog by entries such as:

Jul  7 01:36:12 Tower emhttp: get_config_idx: fopen /boot/config/shares/oldseries.cfg: No such file or directory - assigning defaults

 

Is there a good reason why this is done?

 

I don't need every directory to become a user share and it just clutters things up - can this behaviour be prevented?

 

If I want a user share, I will create a user share ... if I don't want a user share, I don't want the system creating one for me behind my back.

This feature makes recovery of the the array automatic. Why are you manually creating directories in /mnt/user?

 

Turn off sharing in for one of the directories and move all the others into that directory.

This feature makes recovery of the the array automatic. Why are you manually creating directories in /mnt/user?

 

Turn off sharing in for one of the directories and move all the others into that directory.

 

I'm not creating directories in /mnt/user ... the system is doing that.  I'm creating the directories on /mnt/disk1 and /mnt/cache etc.  The system is automatically turning these into user shares.

My mistake. I meant the top levels of the disks. The top level of the disk in unRAID is reserved for shares. This is one of the central and most important features of unRAID. It allows automatic recovery.

/mnt/user is just a joined list of the top level directories on all member disks, it doesn't actually exist.

 

What you are asking for is a feature request, right now all top level directories ARE user shares, you create it when you mkdir on /mnt/disk1...unraid just sees that and lets you set options on it.

 

For instance, I have a disk for my user shares...I exclude that disk from all other shares and set the user directories to only be valid on that disk...then I can use permissions to ensure that users can't see other users data.  You can always do that and put all the data you are trying to stick on /mnt/disk1 under that user top level directory...same net effect.

Under Settings->Share Settings a disk can be excluded.

I don't want to exclude a disk - there are genuine user shares, which I have created, on the disks.

 

My problem is that any files or directories which I create on, for instance, /mnt/disk1 (or /mnt/cache) are getting turned into user shares by the system, even though I haven't asked for them to be, or created them as, user shares.

Change the folder name to start with ".".

 

For example. Change usershare1 to .usershare1

 

That will tell unraid to not add these as user shares.

What we are trying to say is that a directory created on the root of a disk IS a user share, that's what defines them...that they exist in that location.  You /can/ create them from the Web interface, but all that does is a mkdir (and creates a .cfg file, but the .cfg file isn't needed as they don't create shares, just set options for them).  That's how unraid works, in the 5 tree you could (for the first time) control some of this by creating shares that exist only on the cache drive, but they are still user shares.

 

There are a few options that I see, perhaps others can think of more

 

[*]Create a user share, limit it to the disk you are interested in, and put all the data under that.

[*]Add a feature request to allow the functionality you are looking for

[*]Use hidden folders (Good idea mr-hexen, i thought they would be User Shares that would just not be browsable)

[*]Use SNAP to mount disks outside of the array, then share them....use those for the non-user-share directories and set up a cron job to copy the data into the array (with rsync or some such system) so it gets backed up (UGLY!)

 

The thing that makes this tricky is defining what directories should be "user shares" and which should be ignored.  I suppose a complex smb config could have this work, but the simplicity of unraid is a defining feature...so making things more complex needs to have a very good argument behind it.

 

 

 

But I don't want these directories to be hidden!

 

unRAID now has a facility to create a user share from the web gui.  It shouldn't be assuming that all directories are user shares.  User shares are those for which a /boot/config/shares/xxx.cfg file exists.  If there is no specific .cfg file, it shouldn't be automatically generating a user share - should it?

It's about perspective, the cfg file is an optional place to define configuration options for a user share...what DEFINES a user share is that the directory exists. 

 

A user share can exist without a .cfg file, but a .cfg file without the directory is an error

 

...what DEFINES a user share is that the directory exists.

 

I would argue that, under the new scheme, what should define a user share is that the user has gone to the web gui and clicked the 'Add share' button - otherwise, what is the purpose of that button?.  This action creates a .cfg file, just like it does for many other configuration options.  It should now be the existence of this .cfg file which defines the existence of a user share.

 

Edit:

On the other hand, I find that there are user share .cfg files for which there is no entry on the Shares tab in the gui ... perhaps because sharing is turned off for all three protocols. Edit: No, I now think that it's because a corresponding directory doesn't exist on any disk.  However, this means that there are .cfg files which you cannot access in order to edit them.

 

I would argue, very strongly, that the existence of the .cfg file should be the determining factor as to whether a user share exists (and is shown on the 'Shares' tab.

 

Look at it from the point of view of a new unRAID user who has never seen a pre-5.0 version.  He knows that there are disk shares, and user shares.  He creates the user shares he wants, via the 'Add Share' button in the gui.  He then creates a directory on a disk and is surprised that this now pops up as a user share which he didn't want.

 

Edit 2:

I now believe that, from the user perspective, the system would appear to behave sensibly (except for the syslog error messages) if the default settings which are generated whan a .cfg file does not exist did not enable sharing for any protocol.  At the moment the default enables SMB sharing but disables NFS sharing.

 

But ... having entries in the 'Shares' tab for which there is no .cfg, and having a .cfg for which there is no entry in the 'Shares' tab seems to be a little bizarre!

It won't change. As already posted, the system takes every top level directory and combines them into the /mnt/user shares. That's just how it works at the core level.

 

You will have to figure out a way to live with it. I suggest creating a share that is not exported over the network and then storing all these new directories you are creating there. You can make any share not appear over the network if that is the problem.

 

The cfg files with no share are left over from a deleted share. unRAID doesn't delete config files when the directory no longer exists. They are harmless so it's not a big deal.

 

You could post in the 5.0rc forum with the suggestion to not set the share to be accessible over the network by default. I doubt it'll be changed though because that would mean that there many people who use the default and then can't figure out why there is no share on the network just to fix your "issue".

 

Personally, I don't want lots of top level directories because that just creates a mess on the disks....

 

This all came about because I use the cache drive to store non-critical files.  To keep them from being 'movered', I'd created them as hidden directories (with a leading period).  However, it is an annoyance to have to enable viewing of hidden files everytime I want to access them.  So, knowing that the mover script had been modified to not move where there is no target directory to move to, I removed the periods - this was when I noticed a whole new bunch of user shares cluttering up my 'Shares' tab (well, what I actually noticed was the messages appearing in the syslog).

 

I still maintain that, for a new user, with only v5 experience, the presence of the 'Add share' and the automatic appearance of 'unwanted' user shares could be very confusing.

 

I'm not sure how significant a code change would be required to suppress the creation of user shares where there is no .cfg file - logic (and 30 years professional programming experience) tells me that it ought to be fairly straightforward.  It would certainly make V5 functionality and user configuration more logical.  The shift in approach for old pre-v5 users ought not to be too complicated or confusing.

There is a modify mover addon that you could install and instead of a leading "." You create folders with a leading "_". These shouldn't be hidden or touched by the mover script.