Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
Access denied on other users files in AD share
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2011-09-20
12:42 PM
2011-09-20
12:42 PM
Access denied on other users files in AD share
I've got a ReadyNAS 2100 on a windows 2000 AD domain. The NAS is on the domain and can see all of my users and groups but I am having an issue creating shares for group access. I've seen similar threads but none have been successfully solved and none were exactly what I have here.
I've only got CIFS enabled, the firmware version is 4.2.15
The goal is to allow the people in the security group read/write access but no one else.
Here is a step by step of what I do...
The security groups are configured in AD.
Using the web interface for the NAS I create a new share and uncheck 'public access'.
I then select the CIFS option link in the share list.
I set 'Default Access' as disabled.
I check the write enabled box and enter in the AD group name on the 'Write-enabled groups' line.
I enable the recycle bin
Check the 'Automatically set permissions on new files and folders' box and leave everything as the defaults (I've tried various combinations here but none have worked).
Leave oplocks checked.
On the advanced options tab the share folder owner is set to the same name as the share and the group is nogroup. I do not change anything else on this tab.
Any one in the group can access the share and users that are not part of the group cannot so that is working as expected and desired.
However, when a user that does have access to the share creates a new folder or file, or even copies one into the share none of the other users can access them - they receive a permission denied error.
Oddly though, other users can delete any file or folder but not rename them, even though the 'Grant rename and delete privileges to non-owner of files.' on the advanced tab is checked.
When looking at the ACL through windows for the created files and folders the person that created it is listed as the owner and in the list with full control. 'Domain Users' and 'Everyone' are also listed with no permissions.
The ACL for the share root has:
Owner: NAS\shareName
And permissions of
NAS\shareName with full control in this folder only
nogroup with full control in this folder only
Everyone with full control in this folder only
'Creator Owner' with full control in subfolders and files only.
'Creator Group' with none in subfolders and files only.
'Everyone' with none in subfolders and files only.
If I add the security group from AD to the root ACL and give it full control everything works as expected and the correct users have full control and all other have none. I guess my question is why do I need to touch the Windows ACL at all? I didn't think I had to? Or did I do something wrong with the set up?
Sorry for the long post, but I figured better too much than too little detail.
I've only got CIFS enabled, the firmware version is 4.2.15
The goal is to allow the people in the security group read/write access but no one else.
Here is a step by step of what I do...
The security groups are configured in AD.
Using the web interface for the NAS I create a new share and uncheck 'public access'.
I then select the CIFS option link in the share list.
I set 'Default Access' as disabled.
I check the write enabled box and enter in the AD group name on the 'Write-enabled groups' line.
I enable the recycle bin
Check the 'Automatically set permissions on new files and folders' box and leave everything as the defaults (I've tried various combinations here but none have worked).
Leave oplocks checked.
On the advanced options tab the share folder owner is set to the same name as the share and the group is nogroup. I do not change anything else on this tab.
Any one in the group can access the share and users that are not part of the group cannot so that is working as expected and desired.
However, when a user that does have access to the share creates a new folder or file, or even copies one into the share none of the other users can access them - they receive a permission denied error.
Oddly though, other users can delete any file or folder but not rename them, even though the 'Grant rename and delete privileges to non-owner of files.' on the advanced tab is checked.
When looking at the ACL through windows for the created files and folders the person that created it is listed as the owner and in the list with full control. 'Domain Users' and 'Everyone' are also listed with no permissions.
The ACL for the share root has:
Owner: NAS\shareName
And permissions of
NAS\shareName with full control in this folder only
nogroup with full control in this folder only
Everyone with full control in this folder only
'Creator Owner' with full control in subfolders and files only.
'Creator Group' with none in subfolders and files only.
'Everyone' with none in subfolders and files only.
If I add the security group from AD to the root ACL and give it full control everything works as expected and the correct users have full control and all other have none. I guess my question is why do I need to touch the Windows ACL at all? I didn't think I had to? Or did I do something wrong with the set up?
Sorry for the long post, but I figured better too much than too little detail.
Message 1 of 8
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2011-09-22
11:34 AM
2011-09-22
11:34 AM
Re: Access denied on other users files in AD share
Please update your ReadyNAS, as 4.2.15 is out of date.
Additionally, turn off the advanced CIFS permissions if you don't want those settings to change the permissions when people are copying files and folders to that share.
Additionally, turn off the advanced CIFS permissions if you don't want those settings to change the permissions when people are copying files and folders to that share.
Message 2 of 8
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2012-01-11
02:33 PM
2012-01-11
02:33 PM
Re: Access denied on other users files in AD share
Hi,
did you get to the bottom of this? I had a long call with Netgear support and we had to leave the top level shares as default, and manipulate some of the shares via telnet to the nas to check the perms are set..
the issue i had was that no matter what settings i put on the share in the gui, the rights set on the underlying folders just wouldnt stick or failed.. and any files or folders created by a user on a shared drive were ONLY writeable by them even though the whole folder had an inheritance for all the users in a group.
We had to set the top level folders owners etc via the getfacl and setfacl commands to set the correct groups on the folders.
Apparently its a Posix-Windows translation issue, not sure if the Netgear guys are working on a fix or not? now whenever i create a share i go in and check the owner and permissions on the folder.. to make it easier I have one top level share called DATA and i create folders such as Finance, operations etc under there which are then mapped via a login script directly and perms set on these folders rather than mess around with a lot of shares all the time.. seems to be working well now..
let me know if you still have the issue but you would probably be advised to talk to support and get them to do the same as I did, otherwise i can share some of the more in depth troubleshooting steps if you get stuck.
definitely upgrade to 4.2.19 though.
did you get to the bottom of this? I had a long call with Netgear support and we had to leave the top level shares as default, and manipulate some of the shares via telnet to the nas to check the perms are set..
the issue i had was that no matter what settings i put on the share in the gui, the rights set on the underlying folders just wouldnt stick or failed.. and any files or folders created by a user on a shared drive were ONLY writeable by them even though the whole folder had an inheritance for all the users in a group.
We had to set the top level folders owners etc via the getfacl and setfacl commands to set the correct groups on the folders.
Apparently its a Posix-Windows translation issue, not sure if the Netgear guys are working on a fix or not? now whenever i create a share i go in and check the owner and permissions on the folder.. to make it easier I have one top level share called DATA and i create folders such as Finance, operations etc under there which are then mapped via a login script directly and perms set on these folders rather than mess around with a lot of shares all the time.. seems to be working well now..
let me know if you still have the issue but you would probably be advised to talk to support and get them to do the same as I did, otherwise i can share some of the more in depth troubleshooting steps if you get stuck.
definitely upgrade to 4.2.19 though.
Message 3 of 8
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2012-01-11
02:39 PM
2012-01-11
02:39 PM
Re: Access denied on other users files in AD share
Check the current 4.2.20 beta, there were some updates regarding ACL support.
Message 4 of 8
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2012-01-11
03:31 PM
2012-01-11
03:31 PM
Re: Access denied on other users files in AD share
Thanks Grievous, I checked the version notes, couldnt see anything specific in there re the acl's though?
I use my readynas at home as a replication partner for the one which is in production at my wifes business, they have a few virtual servers over nfs hanging off of it so i cant really try a beta there unfortunately.. even so, a beta update to this replication partner might break the replications? when is 4.2.20 going to be released and can you provide those acl details on what was fixed please..
cheers!
I use my readynas at home as a replication partner for the one which is in production at my wifes business, they have a few virtual servers over nfs hanging off of it so i cant really try a beta there unfortunately.. even so, a beta update to this replication partner might break the replications? when is 4.2.20 going to be released and can you provide those acl details on what was fixed please..
cheers!
Message 5 of 8
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2012-01-11
04:33 PM
2012-01-11
04:33 PM
Re: Access denied on other users files in AD share
No, and well, there's a beta with what will likely resolve your issue since it was specifically addressed. The notes do not always include every individual change in every build. Of course I could just go and update the notes, but that's beside the point. You wanted a possible solution, you have one to try now.
edit: Actually I did double check and it is there 6. [T19] CIFS service patch to correct copy/move error in rare situations. that was regarding permissions, specifically inheritance.
edit: Actually I did double check and it is there 6. [T19] CIFS service patch to correct copy/move error in rare situations. that was regarding permissions, specifically inheritance.
Message 6 of 8
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2012-01-11
05:14 PM
2012-01-11
05:14 PM
Re: Access denied on other users files in AD share
thanks, i'll check it out.. i was looking at the T23 post 🙂
Message 7 of 8
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2012-01-11
05:30 PM
2012-01-11
05:30 PM
Re: Access denied on other users files in AD share
Well t-23 would be the build you'd want to use, it's just that the change was made earlier is all.
Message 8 of 8