Unraid SAMBA share permissions messed up?


Recommended Posts

Since updating to 6.10.1 i noticed that my SAMBA shares from Unraid, Active Directory permissions are getting denied (No Permission to view), despite effective access showing correct permissions for this AD group (Unraid is joined to the domain)

 

So, i created a few new shares and tested permissions, I'm not sure if my config files are messed up in Unraid or something has gone pear shaped during the upgrade?

 

Example: I created a new share in Unraid, set it to a private share and exportable, check the permissions, I'm seeing "everyone" getting full read/write access to brand new shares that should be private?

 

Wanting to see if anyone else is seeing this? or just myself?

 

Edited by Darren Cook
fixes to wording
Link to comment

Now, I am NOT running Active Directory.  I have the share set up like this:

image.png.d6a6b36aa218ee933a2249a292beaf56.png

 

When I go to this share (logged-in as the User with the read-only permission) and select a file at random, I can not delete the file but I can copy it back to the client computer.  This is the expected behavior. 

 

What are you seeing?  

 

I admit that I don't have a good handle on what the Domain server does but I have the feeling that it may be not be passing what you think is your login information on to  the Unraid server but using secondary login to group individual users who have identical permissions to a resource together as a group.  Hopefully, someone (with a much better understanding) will jump in and provide more details.

 

It would be helpful if you would post up a screen of your share security setup as I have done. 

Link to comment
6 hours ago, sublimejackman said:

I'm at a work stoppage here with the same issue in 6.10.2.  I have share for security camera backups and I cannot access it from SMB in any environment. I get permission denied for any user. Including just read only. Can't go much longer without access to our backups 

Try running 'New Permissions'   (      Tools       >>>    New Permissions    ) on just the User Share with the problem.

Link to comment

Thanks. I just ended up chmod all the lower directories in the share. It seems to have only impacted about 1/3 of the subdirectories, not all of them. Looking at the log, the permissions were changed when I updated to 6.10.1, I just didn't notice until we did or monthly offsite; at which point we had updated to 6.10.2

 

So def an issue with 6.10.1 that lingers into 6.10.2. No tool in the web GUI would change the sub directories permissions in the share.

Link to comment

I've encountered the same AD issue for the last few days since I upgraded to 6.10.1 (and now 6.10.2).

 

I have permissions issues all over the place. It looks like the Windows "Owner" of the root shares has been reset to Nobody (from Domain Admin) and I can't take ownership no matter what I try. My users are creating files that linux (e.g. a docker container that backs up files) can't access; my copier (which logs in using an UNRAID user) makes files that they can't access. Pretty disastrous.

 

Commenting mostly so I can follow this thread - I'll report back if I find a workable solution.

Edited by nomadgeek
clarity
Link to comment

Update:

I re-owned the shares by looking up the UID & GID for the domain admin (ls -lan) and then chown -R XX:XX share-name got it back to the Domain Admin.. so that's solved - I can edit permissions from Windows again. Doesn't answer the interoperability problem.. I think I can solve the backup software problem by running that container as a UID from AD instead of the default but scanning coming from my copier is a different issue.

 

Link to comment

See my comments in this thread; I've basically worked out all of the conflicting permission problems between linux and windows by (a) never using my linux user to interact with shared files and (b) running the handful of docker containers that need to interact with shared files as a domain user.

 

My only outstanding problem is that winbind seems to 'forget' that a domain user exists which has never happened before. I give more detail in this thread.

 

Edited by nomadgeek
Direct link to post
Link to comment
  • 2 weeks later...

I reverted back to 6.9.2 after reading this and my domain user shares are now working. Having said that it usually took some time before the domain owners home directories would start to appear as unknown in the new file manager, at this point the user would lose access to the server, not the share, the server. "wbinfo -i user" would return an error.

 

Hopefully this wont happen now I'm back on 6.9.2.

Link to comment
7 hours ago, nomadgeek said:

 

Try the solution I added in the other thread below. This solved the 'randomly losing AD users' problem.

 

Awesome, thank you for pointing me in the right direction. Added your settings and so far so good! 

  • Like 1
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.