I'm on the road to updating my UnRAID server from version 6.9.2 to 6.12.6, but before doing this I wanted to make sure that my family's Windows 10/11 PCs are set up correctly security-wise - so no "bypassing security" by enabling SMBv1. So I carefully followed this guide...

 

https://forums.unraid.net/applications/core/interface/file/attachment.php?id=118877

 

I made the changes to my wife's laptop first because she's had some issues accessing SOME sub-folders, while others work fine - all within the same share. I had no such issues.

 

I made the changes, set up a new Read/Write user in the UnRAID Web GUI, and put the credentials into her windows credential manager, and then rebooted both her PC, and the UnRAID server (just to be sure). In testing, I was able to log onto the server OK, and go down several folder levels to try the folders she'd had permission issues with before. The issues are still there. In the third sub-directory down from the share there's a further set of folders all at the same level - (Week 1, Week 2, Week 3, Week 4, Week 5, plus a few random files - see the attached screen-shots).

 

The issue is - using the correctly set up user, she can open the Week 3, Week 4, Week 5 folders just fine, but if she tries to open the Week 1 or Week 2 folders, she gets a 'You do not have permission' Windows message. I didn't think that was possible - you either have access to a share or you don't. I didn't think you could set individual sub-folder permissions.

 

I convinced myself it must be something screwy on her PC (she's on Windows 11). I made the same changes on my Windows PC, and set up the same read/write user in the credentials manager on my PC, and rebooted. Now I have the exact same issue - I can access the Week 3, Week 4 & Week 5 folders just fine, but get the same 'You do not have permission' Windows message as well.

 

This at least proves it's not an individual PC issue - the problem lies within UnRAID somewhere - but I've no idea where to look!

 

So.....should I try to get help sorting this issue out before upgrading to UnRAID 6.12.6, or hope it's just a weird 6.9.2 anomaly, and the upgrade to 6.12.6 will fix it?

 

I'd appreciate a comment from anyone who's encountered this issue before, or knows what it is and how to fix it. (translation: Please Help!) 🙂

I suspect the problem is on the server with the Linux permissions to those folders that she is having the problems with.  There are a couple of approaches that you could try.

 

IF you want to  investigate and troubleshoot the problem, use the GUI terminal  (the icon on the right side of the GUI Taskbar).  Type the following command:

ls -alh /mnt/user

Look at the listing.  You should see something like this:

 

Column 1 is the permissions d = directory;  r = read; w= write; x = execute;  (a ' -'  in place of the 'd' Indicates a simple file) 

    The  permission letter is means the permission is on.  a   -    means the permission is off.

    The first block of rwx is for the owner, the second group is for group, and the third group is for others.

 

Column 2 is the owner

 

Column 3 the group

 

Column 4 is the name of the resource.  (Partially obscured..)

 

Hit the  <up-arrow> key and the command will reappear.  add a   /   and the name of the share that the problem folder is in and hit <Enter>.

Repeat until you get down to the directory/folder with the issue and look at the permissions.  These are the permissions that we expect to find for directories and files in a Share.

 

(Quick explanation.  When you setup your wife as a Shares Access user, that means that she automatically becomes a member of the group 'users' and she actually gains access to directories and files through the group permissions.) 

 

IF you just want to fix it.  Run the New Permissions tool in the TOOLS  tab.  Run it on the Share with the problem.

 

If this does  not fix it, come back with what you are seeing when you us the   ls     command. 

 

EDIT::    Linux is case-sensitive so you must type all Linux commands, resource names and parameters using the proper case!

Edited February 11, 20242 yr by Frank1940

Hi Frankk1940 for such a detailed answer - I REALLY appreciate it!

 

I used the GUI terminal as per your instructions, and got a listing of all the shares in the format shown in your example. FWIW the share with the issue is 'Backups'. Here's a look at the top level...

 

 

Note the "+" symbol on the end of the permissions column for the Backups share. I don't know what that symbol means, but it's the only share that has it. Going in deeper I can now see the permissions values for the different week sub-folders...

 

 

Note the permissions for 'Week 1' and 'Week 2' are VERY different from those for weeks 3-5, AND the Week 1 and Week 2 folders ALSO have the '+' symbol on the end of the permissions column. The other week folders don't have that.

 

This looks to me to at least point to what's causing this issue. It would be nice to understand what the '+' symbol means, and then the only thing left to fix the issue is altering/correcting the permissions for these folders.

 

 

3 hours ago, Roscoe62 said:

Note the "+" symbol on the end of the permissions column for the Backups share. I don't know what that symbol means, but it's the only share that has it.

See here:

     https://www.linuxquestions.org/questions/linux-newbie-8/what-is-in-drwxrwxrwx-915243/

 

The 'New Permissions' Tool in the TOOLS tab will fix these problems.  However, you also need to figure out what program generated these directories and fix the write permission settings on those computers.  (I would be a bit suspicious that some one has set up permissions on a share from Windows:  This is a quote from a section of a Post:

 

Quote

 

Recently, something has come to my attention about Unraid and SMB. There have been incidences where access to Unraid shares is restricted or blocked completely from users who should have access to it. What has been found in these cases is that a feature, has been enable on the Unraid side, called Access Control Lists (ACL for short). This will show up as an ‘+’ at the end of the Linux permissions. See the screen capture below:

 

Note that the ‘+’ is also on the file as well as the share/directory.   ACL changes the way that Linux is going to control access to these resources. After some research, I found out that Windows has used ACL for a long time.  The SAMBA group has added ACL into its version of SMB.  Unraid does not use ACL in its security scheme.

 

At the present time, I can think of only one way that a ACL could be found on any Unraid server. It was done by a Windows user who was trying to change how SMB worked by applying Windows security features to an Unraid share by changing the default Security settings. (Basically, right-clicking on the Share in Windows Explorer, selecting ‘Properties’, then the ‘Security’ tab and working from there.)

 

The point I am making is that you can’t fix a share access problem by trying to change a Unraid share security using Windows security tools on that share. If you try, you will probably make things worst! (Unless you are a Windows SMB Networking Guru…) It is important to realize that if you are denied permission to an Unraid share resource, the problem can only be fixed on the Unraid side using the Tools in the Unraid GUI (or via the command line for specific problems).

 

If you are having an access problem to a Unraid share and can’t solve it with the tools in the GUI, start a thread in the General Support sub-forum and let the community help you fix it.

 

 

This quote comes from this post:  

          https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/#comment-1009109

 

 

 

Again, Thanks Frank1940. Using the 'New Permissions' tool did the trick! Both the Backups share, and the Week 1 & Week 2 folders still have the '+' symbol present, but my wife and I can now access those folders without issue now.

 

As far as isolating the cause - that's harder to do. I'm virtually the sole user until recently, and I set up those folders. I haven't got a clue what I did while setting those folders up, but the extra unwanted security was definitely NOT intentional.

 

I'll take the blame, but still don't know how I did it! Thanks again for sharing the knowledge!