Another user can't write

[pencom]

We have an ReadyNAS Pro 2 with RAIDiator 4.2.20 firmware.

When someone open a file and after save it, the another user can not modify the file just read.
Please help someone what is the right setting for the Share to the users can modify the files.

The user access the files with CIFS.
Default Access: Disabled
Read-only groups: Finance
Write-enabled groups: Finance
Automatically set permissions on new files and folders: Enabled
Do not allow ACL changes to be more restrictive than this: Enabled
Grant rename and delete privileges to non-owner of files: Enabled

Laci

[evan]

Please select "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." in share/advanced options/Advanced Share Permission

[mackadmin]

Hello - I am having the same problem with the same equipment, ReadyNAS Pro 2, Firmware 4.2.19.

User A creates file in a share.

User B is unable to modify that file in the same share (same file, same share, not trying to access at the same time)

I am a new user to the ReadyNAS Pro hardware, so please hang in there with me.

I found the advanced utilities a few days ago and ran it against the said folder and changed the share folder owner and share folder group to the group name (that both of the users are in) and also checked the box for setting ownership and permissions for existing files and folders.... which works for existing files in the folder. However, if User A creates another new file after that, User B is still not able to modify it. I must be missing something as this should be a simple thing to do.

My permissions through CIFS are set up the same as the original poster.

Any help is greatly appreciated.

Tom

[mackadmin]

A little more info on this....

I actually do have the issue working at the level of the share, however, if a user tries to work at a sub folder within the share, and user A creates a file, User B cannot modify it.

Share: stack
Users: User A, User B - both members of a group called stack
CIFS: Default Access is disabled
Write Enabled Users: Blank
Write Enabled Groups: stack
Automatically set permissions: on
Do not allow ACL changes to be more restrictive: on
Next four boxes set to Read/Write

User A can create a file in share "stack" and User B can modify it. Great.

If User A created a file in a sub-folder of share "stack" then User B cannot modify it. Not Great.

I have already gone through the Advanced Settings and updated the ownerships. How do we get the permissions to flow from the main share through the sub-folders?

Thanks -

Tom

[evan]

Hi Mackadmin,
Do you select Read/Write in Advanced CIFS Permission and advanced option?

In share/CIFS/Advanced CIFS Permission, select "Automatically set permissions on new files and folders." , it is useful for new create files and folders in shares.

In advanced option, select "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." it is useful for existing files and folders in shares.

[mackadmin]

Thank you for your reply. Yes, read/write is set in both, and I understand that I can set the ownership with the advanced options, which only works for existing files, and, my user can create files and folders in the share. However, if there is a subdirectory (folder) under the share, and those two users need to share files in there as well, the same does not hold true. In the sub-folder of the share, if a user A creates a file, user B cannot edit it. Do the permissions not flow down through the file system?

Thank you again for your time.

[evan]

Hi Mackadmin,
Please contact support, they can check the background of your system and find the problem, although UI setting is right, maybe background is fail.
https://my.netgear.com/myNETGEAR/support.asp

[de niro]

Looks like your new create folders or files added sticky bit attribute,it will disallow other users to modify them,I don't understand why you couldn't reset permission for all existing files,or you have to contact support center to find assistance.

[clewis]

I'm contending with a similar issue which has just started up since upgrading nearly all users to Win7 pro. They can access the share but cannot consistently acess folders within the share created by someone else or files that are modified by another user within a folder in the share. It's like something (Win7?) is changing the permissions on individual files. I can do as suggested and go into the advanced options and reset the permissions for all existing files, but it's only a matter of time till it happens again.

[evan]

In windows 7, Folder owner right click the folder and open properties, then go to Security\Edit, please select allow Full control in Permissions for Everyone.

[clewis]

I agree, evan...but how can I keep my users from having to even do this step? Is there a Win7 change I can make in secpol or something like that so that the individual user won't try to own the folder to start with?

[clewis]

Netgear support recommended the following steps:
1. upgrade firmware (Radiator 4.1.9 just came out.)
2. Do a firmware reinstall - this wipes admin password and network settings.
3. Reset permissions on affected shares.

Questioning them on step 2 they suggested doing 1 and 3 first to see if any impact before doing 2. I have done 1 and 3. The workgroup impacted by this is out of office for the week so I have to wait till next week to see if the issue is resolved.

Release notes for 4.1.9 mention something about CIFS permissions being part of the bug fixes...so I am hopeful.

I'll try the OS reinstall only if I have to...it's a little scary since it involves powering the machine up while holding the reset button in.

[dps-73]

Having the same issue here. Running 4.2.21 and seem to have the same behavior as your experiencing. The release notes for 4.2.21 also mentioned addressing CIFS issues as the release notes for 4.1.9 did. I just opened a support ticket on this and I hope that Netgear is looking into this issue as it appears to have been an issue for several releases.