(KNOWN ISSUE)Small User Share Bug > Delete share

[Influencer]

Just ran across this. Its very minor and doesn't present any issues with data integrity.

 

I had a share for Emulation, recently I made a share named "Games" to encompass all games and not just emulation. I moved my emulation share over into the newly created Games share. I didn't notice until today that unraid still showed an "Emulation" share, with a size of 0 bytes and Free space of 0 Bytes.

 

The bug I believe comes in from the fact that since I had moved the share into a subdirectory it no longer existed so whatever command unraid uses to determine if a share is empty or not was failing and instead of recognizing the share was gone, unraid stated the share was not empty and I couldn't delete the share. I had to make a new directory on the root of one of my hard drives named "Emulation", then go into unraid settings and delete the share that was now correctly identified as empty.

 

Like I said, very minor and probably not a situation that will come up often, just thought I'd make a note of it.

[limetech]

I'm not sure I follow what you did here....    Can you reproduce the problem?

[Influencer]

I'll try right now and report back

[Influencer]

Alright, I can reproduce it.

 

What I did was:

 

Create new share(did both through the webgui and by manually creating a top-level folder); I named it "Limetest"

Put some random text files in the share so it would show as not empty in webgui.

Through Midnight Commander I moved /mnt/user/Limetest to another share, in this case /mnt/user/Movies

Went back to webgui, the share "Limetest" reports as having a size of 0B even though it no longer exists(since I moved it)

Going into the share settings to delete the share it reports "Share Empty? = No"

 

To delete the share from the settings page I must create a new directory named "Limetest" and then delete from shares menu.

mkdir /mnt/user/Limetest

 

It now reports as "Share Empty? = Yes"

 

 

 

So, if the top level directory no longer exists for whatever reason but was not deleted from the webgui, it appears as not empty and cannot be removed from the user shares page unless the directory is recreated first.

 

Hopefully I explained it better that time

 

 

[limetech]

Ok, I'll try that now... when you say you 'moved' it to another share, this is actually a "rename", correct?

[limetech]

Hey total off-topic question for you since you're on the forum now...

 

Turns out there is a strange behavior with Samba that causes problems in the security model (I'll explain below).  The way I have to fix this is by changing the "New Permissions" script to set permissions as follows:

 

For directories:

  drwxrwxrwx

For read/write files:

  -rw-rw-rw-

For read-only files:

  -r--r--r--

 

In other words, enable permission for 'other' (or 'world').

 

This does not cause any problems for 'stock' file serving use, but since you have a lot of experience with various plugins, wondering what your opinion of the impact of this change might be...  I want to post a release this week with this change in it...

 

Here's the problem.  With 'guest' access, Samba is configured to run as user 'nobody', and this user is in the 'users' group.  This works fine when creating files/directories etc.  But apparently Samba looks at the directory 'other' permissions when traversing directories.  This causes a "no permissions" error when traversing a public share that got created by a non-nobody user.

 

For example, say your windows login name is "moe" and your password is "astooge".  On the unRaid server create a user named 'moe' and give it password 'astooge'.  Now from your windows PC, explore a public share on the unRaid server and create a folder.  This all works as expected, the folder owner/group is "moe/users".  But now try and view the folder contents from some other machine/user that does not have a User entry on the unRaid server.  In this case, as soon as you try to enter the directory owned by moe windows will complain about no permission even though share is public.

 

Anyway it appears that this is designed behavior, though if you go back far enough (to samba 2 for example) it works ok.

 

The fix for this is to enable 'rwx' for 'other' permissions on directories, and as long as we're doing this, may as well give normal files 'rw' 'other' permissions as well.

 

[Influencer]

Ok, I'll try that now... when you say you 'moved' it to another share, this is actually a "rename", correct?

 

By moved I mean moved.

 

Say the directory was:

/mnt/user/Limetest

 

I had another share named "apps":

/mnt/user/apps

 

I moved "Limetest" to inside "apps":

/mnt/user/apps/Limetest

 

After doing so going to the webgui Shares page the "Limetest" share is still there, clicking on it to bring up the settings it reports as not empty so you cannot delete it(and the share is still exported, but cannot be accessed as it doesn't exist)

[limetech]

Alright, I can reproduce it.

...

 

Me too.  Yes this is caused by renaming a top-level (ie, share) directory using something other than the webGui to do it.  You can rename a share just by changing it's name in the Share Settings.

 

I'll have to mark this as a "known issue" and fix this in a post-5.0 release.

[limetech]

By moved I mean moved.

 

Gotcha... this is being caused by the same bug.  If you stop/start array the "empty" share would be gone as well.

[Influencer]

As for the samba issue, I don't think it will adversely affect the plug-ins or any other file really. The plug-ins are all recommended to be ran as nobody:users as it avoids 99% of the permission issues. There are a couple(plex comes to mind) that create their own user, and a couple that have to run as root.

 

I have noticed the issue in samba, I had to re-map one of my HTPC's because I all of a sudden got permission issues.

 

EDIT: Thanks, like I said its a relatively small bug and probably would not be ran across often at all. Just wanted to make it known in the off case someone did run across it an answer would be out there,