Windows network permission issues (access denied)
August 30, 2007 10:39 AM Subscribe
Serverfilter: My office is in the process of migrating to Windows Server 2003 for Fileserving. We constantly have issues with newly created files. Whenever they are placed on the server by a user, the immediately lose rights to do anything with the file. All other users attempting to access the files are also denied. This is just beyond frustrating. Any ideas what is happening and how to fix it?
We already have the domain set up with all the users on it as well as the fileserver added to the domain. We added the domain users with share level and file level access. They are able to access files we placed on there that were restored from backup from the old server. When people create a file or save a file to the server, then close it and attempt to open it again, Windows doesn't know who the owner of the file is, and thus disables access for everyone. We have to go onto the local drive of the server just to get the permissions back to where it knows who the owner is.
We think it may have something to do with the inheritance of permissions across shares. Any help would be greatly appreciated.
We already have the domain set up with all the users on it as well as the fileserver added to the domain. We added the domain users with share level and file level access. They are able to access files we placed on there that were restored from backup from the old server. When people create a file or save a file to the server, then close it and attempt to open it again, Windows doesn't know who the owner of the file is, and thus disables access for everyone. We have to go onto the local drive of the server just to get the permissions back to where it knows who the owner is.
We think it may have something to do with the inheritance of permissions across shares. Any help would be greatly appreciated.
Response by poster: Migrating from Novell Netware. Set up new Domain Controller by manually inputting users. Also have exchange server with mailboxes for users, as well as the fileserver and a few database servers.
posted by ijoyner at 11:07 AM on August 30, 2007
posted by ijoyner at 11:07 AM on August 30, 2007
You do have a CREATOR/OWNER full control permission on the directory, set to cascade?
And you're not using share permissions? Don't use share permissions ever -- there's no reason when you have NTFS. Use filesystem permissions instead, they're much better.
From the actual server console... not remotely, but with your butt in a chair at the server ...when you look at properties of a newly created item, who is the owner?
posted by Malor at 11:38 AM on August 30, 2007
And you're not using share permissions? Don't use share permissions ever -- there's no reason when you have NTFS. Use filesystem permissions instead, they're much better.
From the actual server console... not remotely, but with your butt in a chair at the server ...when you look at properties of a newly created item, who is the owner?
posted by Malor at 11:38 AM on August 30, 2007
Response by poster: It will not tell me who the owner is, just that it is not me. Below is the error I get when i go to file properties, security on a newly placed pdf file that was put on the server yesterday afternoon.
---------------------------
Security
---------------------------
You do not have permission to view or edit the current permission settings for xxxxx.pdf, but you can take ownership or change auditing settings.
---------------------------
OK
---------------------------
If I click OK I just get a Security tab that is completely empty where the users should be listed.
This is the only windows environment I've ever seen this on.
Should we turn share permissions off completely and just turn them on for Everyone and just lock down access at the NTFS level?
posted by ijoyner at 12:14 PM on August 30, 2007
---------------------------
Security
---------------------------
You do not have permission to view or edit the current permission settings for xxxxx.pdf, but you can take ownership or change auditing settings.
---------------------------
OK
---------------------------
If I click OK I just get a Security tab that is completely empty where the users should be listed.
This is the only windows environment I've ever seen this on.
Should we turn share permissions off completely and just turn them on for Everyone and just lock down access at the NTFS level?
posted by ijoyner at 12:14 PM on August 30, 2007
You need to set up permissions in the root folder to allow everyone read write. That way when they copy something it inherits these permissions. Examine the permissions on the folder you are sharing.
SO if S: is mapped to \\server\accounting look at the accounting folder on that server. What are its permissions? Note: anything in the deny field takes precedence over anything in the allow field. You may have full control but one deny write in there will cause problems like this. Dont use any denys unless you absolutely have to. For a shared drive you shouldnt be using them anyway.
posted by damn dirty ape at 1:24 PM on August 30, 2007
SO if S: is mapped to \\server\accounting look at the accounting folder on that server. What are its permissions? Note: anything in the deny field takes precedence over anything in the allow field. You may have full control but one deny write in there will cause problems like this. Dont use any denys unless you absolutely have to. For a shared drive you shouldnt be using them anyway.
posted by damn dirty ape at 1:24 PM on August 30, 2007
I'd first suggest setting the containing folder to have Administrators/Full Control, with the setting for child objects to automatically inherit permissions. Then look to see what the owner is.
If the owner is correct, then you just need to set up permissions. What I usually do is create three local (machine) groups for any given share.... I call them Share Name RO, RW, and Admin. Then I put organizational groups from Active Directory into those local groups, and then put people into the Active Directory groups. (I haven't worked in Active Directory for several years... I think I'm using NT 4.0 terminology, but the basic approach is the same.)
Example, say I have a Bookkeeping share. On the machine hosting it, I will make three local groups: "Bookkeeping RO", "Bookkeeping RW", and "Bookkeeping Admin". Then I'll put global groups in those... Accounting, for instance, would probably go in the RW group, and managers would probably go in the RO group. Finally, I set the NTFS permissioins... the share folder gives access only to the three groups I created, and cascades permissions.
To do this right, accounts go in global groups, global groups go in local groups, and local groups are assigned permissions. This will optimize your network traffic; if you assign permissions on NTFS to accounts or groups that aren't on the local machine, a lot of extra network lookup traffic is generated. By doing it this way, the server does one Active Directory lookup when a user first connects, and then doesn't have to go back to the network for further permissions checks. They're all handled locally.
This is a little more complex to set up, but it means that you never, ever have to touch the filesystem again. All you have to do is move people around in groups in your Active Directory, and they automatically get all the right permissions after logging out and logging back in. If Fred transfers from Accounting to, say, programming, just moving him in the global groups will fix all his permissions instantly, without you ever having to touch the filesystem on any machines at all. It means that permissions are an offshoot of your organizational structure: if you get people in the right groups, everything just works.
posted by Malor at 4:00 PM on August 30, 2007 [1 favorite]
If the owner is correct, then you just need to set up permissions. What I usually do is create three local (machine) groups for any given share.... I call them Share Name RO, RW, and Admin. Then I put organizational groups from Active Directory into those local groups, and then put people into the Active Directory groups. (I haven't worked in Active Directory for several years... I think I'm using NT 4.0 terminology, but the basic approach is the same.)
Example, say I have a Bookkeeping share. On the machine hosting it, I will make three local groups: "Bookkeeping RO", "Bookkeeping RW", and "Bookkeeping Admin". Then I'll put global groups in those... Accounting, for instance, would probably go in the RW group, and managers would probably go in the RO group. Finally, I set the NTFS permissioins... the share folder gives access only to the three groups I created, and cascades permissions.
To do this right, accounts go in global groups, global groups go in local groups, and local groups are assigned permissions. This will optimize your network traffic; if you assign permissions on NTFS to accounts or groups that aren't on the local machine, a lot of extra network lookup traffic is generated. By doing it this way, the server does one Active Directory lookup when a user first connects, and then doesn't have to go back to the network for further permissions checks. They're all handled locally.
This is a little more complex to set up, but it means that you never, ever have to touch the filesystem again. All you have to do is move people around in groups in your Active Directory, and they automatically get all the right permissions after logging out and logging back in. If Fred transfers from Accounting to, say, programming, just moving him in the global groups will fix all his permissions instantly, without you ever having to touch the filesystem on any machines at all. It means that permissions are an offshoot of your organizational structure: if you get people in the right groups, everything just works.
posted by Malor at 4:00 PM on August 30, 2007 [1 favorite]
One other thought I just had... be careful with 'DENY' permissions. They always take precedence. Basically, Windows looks for any possible excuse it can find to deny access; it gives permission only grudgingly.
This leads to the common mistake of assigning DENY to the Everyone group, and then assigning full control to a specific user account. When the user tries to access the file.... denied! Denial always takes precedence; his Full Control permission is never even examined, because the machine found a reason to tell him to get lost.
Basically, don't use Deny permissions. If you don't explicitly allow a permission, it's denied anyway. The only time you'd need them is to block a specific person or group from something they would otherwise have access to. Usually, that means your global groups (the ones that describe groups of people) aren't granular enough. You should be attacking the problem at the organizational level, not putting specific block permissions into your filesystem.
posted by Malor at 7:47 PM on August 30, 2007
This leads to the common mistake of assigning DENY to the Everyone group, and then assigning full control to a specific user account. When the user tries to access the file.... denied! Denial always takes precedence; his Full Control permission is never even examined, because the machine found a reason to tell him to get lost.
Basically, don't use Deny permissions. If you don't explicitly allow a permission, it's denied anyway. The only time you'd need them is to block a specific person or group from something they would otherwise have access to. Usually, that means your global groups (the ones that describe groups of people) aren't granular enough. You should be attacking the problem at the organizational level, not putting specific block permissions into your filesystem.
posted by Malor at 7:47 PM on August 30, 2007
What damn dirty ape and Malor said, and yes, you should change your share permissions to Full Control for Everyone and rely totally on NTFS permissions for access control. Share permissions only exist because when Windows file sharing was first released, the file system then in use (FAT) didn't have any form of access control. They're obsolete now, and using them will usually cause you nothing but grief.
I only use share permissions for one specific job at my sites: I give Everyone a share permission of Read, instead of Full Control, on the share for the root of the backup drive. Since all the files in the backup drive are Robocopy copies of the originals, with NTFS permissions identical to those of the original files, this is a very easy way to do appropriate access control for backups.
The backup drive also has Volume Shadow Copy enabled, which means that users can easily get to any backup version made in the last two months.
posted by flabdablet at 9:55 PM on August 30, 2007
I only use share permissions for one specific job at my sites: I give Everyone a share permission of Read, instead of Full Control, on the share for the root of the backup drive. Since all the files in the backup drive are Robocopy copies of the originals, with NTFS permissions identical to those of the original files, this is a very easy way to do appropriate access control for backups.
The backup drive also has Volume Shadow Copy enabled, which means that users can easily get to any backup version made in the last two months.
posted by flabdablet at 9:55 PM on August 30, 2007
One more thing: when you're setting up your NTFS permissions, you don't want to give Allow Full Control permissions on any file or folder to anybody but Administrators. Allow Modify permission is plenty for people who need full read/write access. The difference is that Full Control lets you change permissions and/or take ownership, but Modify doesn't. Giving your users the ability to lock Administrators out of their files doesn't actually help them (because Administrators can always Take Ownership and then alter the permissions anyway); it's better to stop them trying.
You'll find that by default, CREATOR OWNER gets Full Control permissions on any object in the root of a drive, and that this permission is inherited. I recommend changing that to Modify.
posted by flabdablet at 10:01 PM on August 30, 2007
You'll find that by default, CREATOR OWNER gets Full Control permissions on any object in the root of a drive, and that this permission is inherited. I recommend changing that to Modify.
posted by flabdablet at 10:01 PM on August 30, 2007
Agreed with flabdablet. Creator/Owner permissions will give you trouble if you change the groups around or if people move in your organization. If Bob from QA moves to Programming, he'll still have access to all the files he made while in QA.
Again: make groups describing permissions and assign the actual permissions to those and ONLY those. (remove creator/owner and direct administrator permissions). Make groups describing people and put user accounts there. Then put groups of people in permissions groups.
If you do this correctly, as people join, leave, and move around, changing what people-groups they're in will magically update their permissions all over your company, no matter how many servers and shares you have.
It's very easy to get ACLs (access control lists) wrong, so keep your ACLs as simple as you possibly can, and use group management as your primary administrative interface. This will save you endless hassle.
posted by Malor at 7:14 AM on August 31, 2007
Again: make groups describing permissions and assign the actual permissions to those and ONLY those. (remove creator/owner and direct administrator permissions). Make groups describing people and put user accounts there. Then put groups of people in permissions groups.
If you do this correctly, as people join, leave, and move around, changing what people-groups they're in will magically update their permissions all over your company, no matter how many servers and shares you have.
It's very easy to get ACLs (access control lists) wrong, so keep your ACLs as simple as you possibly can, and use group management as your primary administrative interface. This will save you endless hassle.
posted by Malor at 7:14 AM on August 31, 2007
Malor's preferred group organization strikes me as a very Unix-like way to go about things, and will therefore probably work extremely well :-)
But if you're feeling adventurous and flexible after getting the current problem squared away, and you actually do want to be able to delegate some degree of access control to some of your users without creating a big stinking mess, there's a CREATOR GROUP pseudo-user you might care to use where Windows would otherwise suggest you use CREATOR OWNER.
CREATOR OWNER and CREATOR GROUP are "place-holder" security accounts: rather than saying anything about who has access to the folders they're applied to, they say something about who will have access to things created inside those folders.
If you have a folder with Allow Modify permission for CREATOR OWNER, and Bob is able to create a new file inside it by virtue of some other permission, then that file will get Modify permission for Bob. If Bob creates a subfolder rather than a file, then that subfolder will get Modify permission for both Bob and CREATOR OWNER.
Note that Bob's new folder will not automatically get Bob as the owner; the owner will be inherited from the parent folder. The only ways for Bob to make a file or folder that he actually owns are (a) create it inside another folder he already owns (b) take ownership of a file or folder he has Full Control permission on. This is one of the ways in which Windows/NTFS and Unix file-security models are quite, quite different.
In fact CREATOR OWNER really should have been called CREATOR USER, since it has nothing to do with ownership.
CREATOR GROUP works similarly, except that instead of Bob the user inheriting the permission specified by the containing folder's CREATOR GROUP permission, Bob's primary group will. So if Bob's primary group is Accounting, and Bob creates a subfolder of a folder that has Modify permission for CREATOR GROUP, then that subfolder will end up with Modify permission for both CREATOR GROUP and Accounting, and any other user in Accounting will be able to go in there and make changes.
When you're setting up users with Active Directory, you may have seen a little box that says that if you're not doing Mac or Unix stuff, the primary group doesn't matter. If you're using the CREATOR GROUP permission on any NTFS file system you manage, this is a lie.
CREATOR OWNER and CREATOR GROUP permissions can be handy things to apply to folders that get shared company-wide. If you have a folder owned by Domain Administrators, with Allow Modify for CREATOR GROUP, Allow Read&Execute for Everyone, and Allow Create File/Create Subfolder for Everyone, then you end up with a spot where anybody can put stuff for everybody to see, but Marketing can't vandalize Engineering's spec sheets and nobody can temporarily lock the admins out. It works quite well.
posted by flabdablet at 8:17 PM on August 31, 2007
But if you're feeling adventurous and flexible after getting the current problem squared away, and you actually do want to be able to delegate some degree of access control to some of your users without creating a big stinking mess, there's a CREATOR GROUP pseudo-user you might care to use where Windows would otherwise suggest you use CREATOR OWNER.
CREATOR OWNER and CREATOR GROUP are "place-holder" security accounts: rather than saying anything about who has access to the folders they're applied to, they say something about who will have access to things created inside those folders.
If you have a folder with Allow Modify permission for CREATOR OWNER, and Bob is able to create a new file inside it by virtue of some other permission, then that file will get Modify permission for Bob. If Bob creates a subfolder rather than a file, then that subfolder will get Modify permission for both Bob and CREATOR OWNER.
Note that Bob's new folder will not automatically get Bob as the owner; the owner will be inherited from the parent folder. The only ways for Bob to make a file or folder that he actually owns are (a) create it inside another folder he already owns (b) take ownership of a file or folder he has Full Control permission on. This is one of the ways in which Windows/NTFS and Unix file-security models are quite, quite different.
In fact CREATOR OWNER really should have been called CREATOR USER, since it has nothing to do with ownership.
CREATOR GROUP works similarly, except that instead of Bob the user inheriting the permission specified by the containing folder's CREATOR GROUP permission, Bob's primary group will. So if Bob's primary group is Accounting, and Bob creates a subfolder of a folder that has Modify permission for CREATOR GROUP, then that subfolder will end up with Modify permission for both CREATOR GROUP and Accounting, and any other user in Accounting will be able to go in there and make changes.
When you're setting up users with Active Directory, you may have seen a little box that says that if you're not doing Mac or Unix stuff, the primary group doesn't matter. If you're using the CREATOR GROUP permission on any NTFS file system you manage, this is a lie.
CREATOR OWNER and CREATOR GROUP permissions can be handy things to apply to folders that get shared company-wide. If you have a folder owned by Domain Administrators, with Allow Modify for CREATOR GROUP, Allow Read&Execute for Everyone, and Allow Create File/Create Subfolder for Everyone, then you end up with a spot where anybody can put stuff for everybody to see, but Marketing can't vandalize Engineering's spec sheets and nobody can temporarily lock the admins out. It works quite well.
posted by flabdablet at 8:17 PM on August 31, 2007
« Older Don't want to hurt annoying/tedious person's... | What to do in place of the missing "X" on the back... Newer »
This thread is closed to new comments.
posted by k8t at 10:51 AM on August 30, 2007