ReadyNAS Pro - file/folder access permissions

It would probably help to focus on one share at a time and ensure access is setup appropriately. From that, any changes that are required may then be applied to the other shares.

Could you describe in detail how one particular share is setup? Maybe post screenshots of the settings. Make sure you include how user accounts and groups are setup also

Fyi - this post may also provide some insight as it seems to match what you are trying to do

I have the same/similar problem with my ReadyNAS PRO which started a couple weeks ago when I upgraded from 4.2.15 to 4.2.17. I posted the problem on this forum and submitted a Netgear support ticket without even a simple acknowledgement about the issue. During that time, I have been testing various configurations for the share access settings and using SSH to watch the file permissions changing on the PRO. The CIFS file permission behavior under 4.2.15 is different than under 4.2.17 and just this morning might have figured out a remedy. We have started implementing the configuration changes today but will takes us a few days to get all the file permissions corrected. The following is what I have observed with our PRO unit and what changes have been made to correct the problem. I don't know if your situation is the same but best of luck in trying to get it resolved.

---------------------------------------------------------------
Problem:

After upgrading from 4.2.15 to 4.2.17, my group started having permission accesses problems where one person could modify a file and another would not be able to modify the same file even though they created the file. Using SSH, I could watch a file's permissions change as the file was modified:

Under 4.2.15:

- Before any change, a file would have the following:

-- File001 - Owner:Sam; Group:users with permissions of 770

- After Bill modified the file, the permissions would change to:

-- File001 - Owner:Bill; Group:users with permissions of 770

Since the Group before and after was Read/Write, the next user was able to modify this file and they would become the new owner and all was good.

Now under 4.2.17:

- Before any change, a file would have the following:

-- File001 - Owner:Sam; Group:users with permissions of 770

- After Bill modified the file, the permissions would change to:

-- File001 - Owner:Bill; Group:users with permissions of 740

Since the Group was changed to Read/Only, the next user (Sam) was only able to Read this file but not modify it. Only the new owner (Bill) was able to modify the file.

To resolve this issue, for the past two weeks, the PRO administrators had to log into SSH and perform the following command to add back in the Read/Write permissions:

> chmod -c -R g+rwx *

Since all of the files within the share points had similar permissions, performing this command within the share point did not harm anything ... at least nothing that we have seen yet. I believe that the same permission update can be performed through the GUI under the Advanced Share Permission section of the Shares. Once the Group permissions had the Read/Write, anyone within the group was able to modify the file and subsequently "lock" it when the Group permission would get put back to Read/Only.


Solution:

I also had "Opportunistic Locking" enabled prior to the permission issue and disabled this option to see if it would help but it did nothing.

Under the "Advanced CIFS Permission" section of the CIFS Share configuration, all of the share points had been configured to NOT use the "Automatically set permissions on new files and folders." option. During some initial testing when we first got this unit about two years ago, selecting/deselecting this option did not appear to do anything so we left it unselected since that was the default when creating a share.

Under 4.2.15, the default "Share folder owner" and "Share folder group" were both set to "admin". However, under 4.2.17, the default "Share folder owner" was the name of the newly create share point (say: TestShare) and "Share folder group" was assigned to the "nogroup" group name. Not sure what was changed in the default configuration between 4.2.15 and 4.2.17 but the behavior is different.

Now getting back to the "Automatically set permissions on new files and folders." option. When I enabled this option and then selected the New File Group Rights of Read/Write and Everyone Rights as Disabled; and New Folder Group Rights of Read/Write and Everyone Rights as Disabled, then the following file permissions were noted:

- Before any change, a file would have the following:

-- File001 - Owner:Sam; Group:users with permissions of 770

- After Bill modified the file, the permissions would change to:

-- File001 - Owner:Bill; Group:users with permissions of 660

Since the Group before and after were Read/Write, the next user was able to modify this file and they would become the new owner and all is now good again. Since we do not need the files to be tagged as executable, the 660 permission works just fine. Even though the GUI text states that the option is for NEW files and folders, it does have an affect on current files and folders.

We are now in the process of updating all the share point access permissions so that New Files and Folders will have the Group Rights of Read/Write and Everyone Rights as Disabled; and updating all the file permissions on all the files to add back in the ability for Group Read/Write access. Hopefully, these changes will return the unit back to its usable state without having the users contact us everyday because they cannot access the files.

I hope I have explained everything clearly and that you examine your situation before making any updates! :D

Best Regards

@Klayson - you've identified what I expect to be the OP's issue, but rather than assume I asked for the full overview.

Re the Ownership changes you see: There are a number of applications that, when editing a file, make a temporary copy of the original file, apply edits to the temporary copy, and then when the file is saved the original file is deleted and the temporary file being worked on renamed with the original file name. (MS Office apps seem to work this way)

This is a "safety" feature to prevent file corruption as the original file is never edited directly, but it has the side effect that in reality the editing user creates a new file and so the rights and ownership are assigned according to the editing user.

With that in mind, the other issue that the OP may then be experiencing is if users with different primary groups are creating & editing files which, if the above method is used, would result in a group change after the file is edited, and irrespective of the "Automatically set permissions on new files and folders" settings for groups may make the file inaccessible. The only practical solution here is to also ensure everyone permissions are set to read/write.

Hope that makes sense

The way different apps handle files does make sense and explains why some files change and others do not. As for the everyone permissions set to read/write, all of our users are in the same primary group so we should not see that issue. However, it is good to know about it so that if we see any problems, we can modify our configurations.

Thanks for the info :D

Hi sphardy and Klayson,

Thanks for your responses. In regards to the "automatically set permissions for new files and folders" feature, we have always had this enabled. I believe that, like in Klayson's case, our troubles started when we upgraded firmware to 4.2.17.

Here is how we have the Managers share set up.


'mcdonaldsit' is the account that I and my colleagues use to access the shares through mapped network drives in Windows.




Please note that I have tried changing the share folder owner to 'nobody' and this did not make any difference.

Oplocks is currently disabled for this group, which is a change I made yesterday to see if anything would improve. I have had an email from someone today complaining that they cannot access a file in the Leaders share now, so I can confirm that oplocks has not changed anything.

There is a select number of users who are a part of the 'management' group, who are also a part of the main 'users' group.

With that in mind, the other issue that the OP may then be experiencing is if users with different primary groups are creating & editing files which, if the above method is used, would result in a group change after the file is edited, and irrespective of the "Automatically set permissions on new files and folders" settings for groups may make the file inaccessible.

All of the users on the NAS have 'users' as their primary group.

I haven't tried setting "everyone" rights to disabled... perhaps I should try this?

@Chels.P - I would have to recommend you open a case with Netgear Support.

There are 2 elements to "permissions" on ReadyNAS devices: 1) restricting who can and cannot get access to the share and 2) how permissions of files within the share are managed by those users who can access it

Clearly you have (1) setup OK as that is not the problem you are reporting.

But for (2), what you show is the share being as open as is possible - all rights are Read-Write and you also prevent Windows over-riding those settings with the "Do not allow ACL changes to be more restrictive than this". What you have is what I would always recommend as a starting point when diagnosing permissions issues and *then* slowly make restrictions as needed (then finding the problem setting as permissions are restricted step by step)

So having your issue with the share being fully open, and this seeming to coincide with the upgrade to 4.2.17, suggests to me a problem with the ReadyNAS firmware that Tech Support should be involved in helping you with.

You don't mention which version of Windows your users have - that may also have some bearing. If it is XP I can try to replicate the issue, but if it is Vista or Win7 I'm afraid I don't have access to those. Maybe another user can test this out for you. But I'd still recommend logging a case with tech support. Details of how to do that are in the FAQ (see top right of the page for link)

Hi sphardy,

Thanks for your help. I was kind of hoping you wouldn't say contact support. Lol. I had to deal with them ALL last weekend trying to get an urgent issue fixed on the NAS and they were awful. I had to call multiple times and each time I spoke to a different person.. and at one point when I called they said they had no record of my case number!
I would like to state though that once I got put in touch with a level 3 support technician in the States, he was awesome.

Anyway - some users are using XP, but most are using 7.

I will call support next week. Thanks again, I appreciate your time.

@Chels.P, @sphardy,

Have you found a solution to this problem? I recently purchased a ReadyNAS ultra, and installed it for my family's use (it replaces a Windows Home Server machine that died an untimely death). So far, the ReadyNAS is great, except that I'm experiencing the very problem in this thread. For example, I have a share called "Photos". If I create a folder in that share, say Photos\LaborDay, then I am able to add pictures to that folder. But my wife, logged in to another computer with her own account, cannot add photos to that folder.

I've ready through this thread pretty thoroughly, and tried all of the various settings. I, too, am able to temporarily solve the problem by clicking the box under "Advanced" -> "Set ownership and permission for existing files and folders in this share to the above settings. This option is useful in cases where you are changing security levels and need to workaround file access problems."

Let me know what you've heard.

-A.J.

I have what is likely the same problem with backup copies of shares created via rsync.

If I backup a share from an older sparc based readynas (an NV+) to a newer intel based device (and ultra 6 plus) , and then mount the share from the Ultra; the parent share directory has read/write access, but subdirectories are read only.

If I backup a share from the Ultra to the NV+ and mount the share from the NV+, then both the share directory and subdirectories are read-write, which is the behavior I desire.

Both the NV+ and the Ultra have the latest beta firmware, 4.1.8-T9 and 4.2.19-T4 respectively (I'm a Mac user)

Any further info on the issue covered in this topic would be greatly appreciated!