unRAID OS Version: 6.1.8 - virgin install... no plugins yet

 

Description:

I recently upgraded from 4.7 to 6.1.8 (clean install).  Brought array online and ran 'New Permissions' per guide.  Not all directories reflect rwxrwxrwx permissions.

 

How to reproduce:

Create a directory with permissions 500 (r-x------) and then run 'New Permissions'.

 

Expected results:

According to the documentation, after running 'New Permissions' the directory will be changed to rwxrwxrwx.

 

Actual results:

Directory instead shows as r-xr-xr-x.

 

Other information:

It looks like the script assumes the write permission already exists for user.  If it does not then there's no write permission to be copied to group and other via the 'go+u'.  If this is the intentional operation then can the documentation reflect it?

 

I don't know why I have directories without the write permission for user but for some reason I do.

 

I did not attach a log as there is no error logged.

This seems in contradiction to the experience of others, at least no other has reported anything similar that I know of.  Can any user confirm this?

 

I don't have any idea, to explain why it happened to you.

 

Confirmed by others below, thank you.

 

So it appears either the script or the documentation needs to change.

The script performs as it should.  The problem is that the docs are not clear, for non-Linux experienced users.  (They are fine for those with Linux experience.)

In the past I have experienced this problem with directories not having write permissions and the new permissions script does not fix it;  I had to manually fix it myself using chmod.

Having had a quick look at the newperms script, it will perform exactly as detailed in the original post.

 

Part of the action of newperms is to replicate the user read/write permissions to the group and other permissions

 

Therefore if the user permissions does not have write access, then after newperms has run neither will the group or other permissions have write access (even if the group/other had write access before newperms was run)

 

I guess the question is whether the newperms script should add write permissions, or is the current behaviour correct, as there may be good reasons for not wanting to allow users to change a file or directory.

Nerperms works fine and exactly as commented in the script.

 

I dont know where people ever got the notion that it would simply do a chmod 777 on a file.

Possibly because the help in the webui for the new permissions tool says that directories will be set to drwxrwxrwx

 

For reference from 6.1.9

 

This is a one-time action to be taken after upgrading from a pre-5.0 unRAID server release to version 5.0. It is also useful for restoring default ownership/permissions on files and directories when transitioning back from Active Directory to non-Active Directory integration.

This utility starts a background process that goes to each of your data disks and cache disk and changes file and directory ownership to nobody/users (i.e., uid/gid to 99/100), and sets permissions as follows:

For directories:
  drwxrwxrwx

For read/write files:
  -rw-rw-rw-

For readonly files:
  -r--r--r--

Clicking Start will open another window and start the background process. Closing the window before completion will terminate the background process - so don't do that. This process can take a long time if you have many files.

I've looked at the script and the descriptive text with the tool (displayed by NAS above), and the script does perform the way it should.  The problem is that the docs are not clear, for non-Linux experienced users.  They are fine for those with Linux experience.  The script itself is not readily accessible or comprehensible by new users with little Linux experience.  And there's no Help available.

 

If you're from a Windows background, you're going to read "For directories:  drwxrwxrwx", and almost certainly wrongly interpret that to mean both folders and files.  The part below that says "For readonly files:  -r--r--r--" will be ignored, as odd and not making sense.  The easy assumption is that it's going to make all files uniformly read/write.

 

It would be nice therefore if the descriptive text could clarify what actually happens, and destroy the wrong assumption.  It needs to be clear that if a file does not already have write permission, it won't receive write permission by this tool.  There's no help available here either, might be nice to add some, although it would be mostly redundant.

 

The identical concerns also apply to the 'Docker Safe' version of the 'New Permissions' tool.

The identical concerns also apply to the 'Docker Safe' version of the 'New Permissions' tool.

Because the "docker safe" version utilizes LT's script and just specifies which shares to run against.  I too noticed some weird little anomalies when there were some strange preexisting permissions, and ultimately decided that the script did in fact work as advertised however.

I've looked at the script and the descriptive text with the tool (displayed by NAS above), and the script does perform the way it should.  The problem is that the docs are not clear, for non-Linux experienced users.  They are fine for those with Linux experience.  The script itself is not readily accessible or comprehensible by new users with little Linux experience.  And there's no Help available.

 

If you're from a Windows background, you're going to read "For directories:  drwxrwxrwx", and almost certainly wrongly interpret that to mean both folders and files.  The part below that says "For readonly files:  -r--r--r--" will be ignored, as odd and not making sense.  The easy assumption is that it's going to make all files uniformly read/write.

 

I guess I have to disagree with you here.

 

I am quite happy what the help text says about files as that correctly describes what the utility does.

 

It is the description (displayed by NAS above) about the directories that is wrong ..... It should make the same distinction between permissions that the file description does, namely that a read only directory produces dr-xr-xr-x permissions and a read/write directory produces drwxrwxrwx permissions.  That is what the original post is reporting .... The mismatch between the action and description of directory entries (not files).

 

At the moment the text implies that all directory entries are made drwxrwxrwx which is not true.