Certain shares have changed permissions - unclear as to why


Recommended Posts

This week I was toying around and noticed an issue with permissions that I haven't been able to figure out. I have a handful of shares that are all set up as Export=Yes Security=Private and I have granted one of my users Read/Write permissions to the share. I was then trying to mount some of the shares on a windows box and realized that one of the shares was in read-only mode for some reason. I could access the files but not create anything new and strangely all of the other shares worked fine. After doing a little digging I noticed the following:

 

image.png.6e3e656dbbda1e110ceaedb2a21c547d.png

 

For whatever reason my "security" share and my "downloads" share have different permissions than I would expect. In fact, they also are different from each other as well.

 

My simple fix was to just delete the security share I was trying to add and recreate it but I'm trying to figure out what might have happened to cause these shares to get their permissions changed so I can make sure I don't mess it up again in the future.

 

Any ideas? I know for a fact I have only ever interacted with the security share directly from the web UI but I did have a docker hooked up to it at one point so perhaps that docker was able to change something about it?

Link to comment

Usually these problems occur because a Plugin or Docker has created the directory (or file) and has set the permissions wrong. (If this is the case, look at the  configuration files to see what they specify.)  The easy way to fix this to run the 'Docker Safe New Perms' (which is a part of the Fix Common Problems plugin).  You can use the Unraid 'New Permissions' utility if you only select the shares which have the issue.  (These would normally be the user data shares.)  These tools would be found under the Tools tab.

Edited by Frank1940
Link to comment

Is it necessarily a problem? General Unraid permissions (mode 777) are ridiculously lax. Even the permissions on the folders indicated are unnecessarily generous. I'd like to see a general tightening up of permissions in the interests of security. The changes in the recent Unraid 6.8.0-rc1 release are a step in the right direction and I hope there are more to come.

Link to comment
18 minutes ago, Frank1940 said:

Usually these problems occur because a Plugin or Docker has created the directory (or file) and has set the permissions wrong. (If this is the case, look at the  configuration files to see what they specify.)  The easy way to fix this to run the 'Docker Safe New Perms' (which is a part of the Fix Common Problems plugin).  You can use the Unraid 'New Permissions' utility if you only select the shares which have the issue.  (These would normally be the user data shares.)  These tools would be found under the Tools tab.


That's what I was thinking but the securityshare was created manually by me via the unRaid wen UI. If I exposed the share to a docker is it possible that the docker could have changed the permission on the share itself? or can it only change the things inside of it?

 

Either way good to know about the Docker Safe New Perms. I have Fix Common problems but hadn't looked there to be honest.
 

5 minutes ago, John_M said:

Is it necessarily a problem? General Unraid permissions (mode 777) are ridiculously lax. Even the permissions on the folders indicated are unnecessarily generous. I'd like to see a general tightening up of permissions in the interests of security. The changes in the recent Unraid 6.8.0-rc1 release are a step in the right direction and I hope there are more to come.

In my particular scenario it is a problem as I was attempting to have my "security" share available to a windows VM to write security cam recordings to so write access is pretty important. I understand and agree with the idea of 777 in general being scary though.

Link to comment

Do a little investigating of the File system for Unraid using the terminal.  You will notice that the files/directories that have 'nobody' as the owner are data files. Using Google,  You will find that the  'nobody'  user is virtually powerless.  Basically, it is the 'group' and 'other' permissions that count.  When you use SMB, it is the Security settings that you set that is controlling  access.  You can determine who can see and read, write, and execute.  With Linux/Unix, the permissions on the directories have different meanings than on files.  There may be security risks involved with the way that LimeTech has setup the permissions on the data files and there might have to be even more changes in the future but I would hope that these changes are actually addressing verified security risks and not someone just thinking that a 777 permission should never be used because it seems like it might not be secure. 

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.