NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Chels_P
Jun 15, 2011Aspirant
ReadyNAS Pro - file/folder access permissions
Hi everyone, I've contacted Netgear support about this issue but they are too slow so I thought I'd try my luck here. I work for an IT management company and I manage the ReadyNAS Pro for one of...
Klayson1
Jun 15, 2011Aspirant
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
---------------------------------------------------------------
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
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!