Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a Windows Server 2008-r2 machine with a share. I have one admin user and 3 standard users accessing this share.
I have an application being run by the admin user (but not run as Administrator) that makes new directories and copies files into those directories.
The share gives everyone read access and Administrators full control. In addition, security for the share gives Read & execute permission to the 3 standard users. When adding the permissions for the 3 standard users, I did a "Replace all child object permissions with inheritable permissions from this object". Fact is I tried without and then tried with.

Ok. Here's my problem:
At the time I give permissions, all 4 users have access to all folders and files. However, when the app makes a new folder and then copies files into it, the 3 standard users have proper permissions for the folder but no permissions on the files (Effective permissions on the files show as none). If I redo permissions, then the files I had problems with work, but again, new files do not. I did change 1 of the 3 users into an Admin and confirmed that all file access works as expected.

So what am I missing? I assume it has something to do with copying the files, as creating the folders give them the proper permissions.

Update: based on @Zordache's comments, I have done the following:

  • Added a group, added 3 users to that group, removed individual permissions.
  • Gave that group similar permissions on the directories the files were being moved from.

So I have now confirmed that permissions are correct on a file moved from an input directory. I have also confirmed that new files coming in behave properly. Problem solved.

share|improve this question
    
BTW, is this mystery application actually creating files in the destination directory, or is it moving them from some other location? When files get moved, within the same volume, then permissions are not updated. –  Zoredache Jan 23 '12 at 17:32
    
Just confirmed that it is a file move and not a copy. There are some copies that happen, but in this specific case, it is a move. –  Joel Rondeau Jan 23 '12 at 17:50
    
@Zoredache, if you add this comment into your answer, once I confirm that a new file works correctly, I'll accept the answer. thanks. –  Joel Rondeau Jan 23 '12 at 18:04

1 Answer 1

up vote 2 down vote accepted

Rule #1 of working with permissions is to never setup permissions per-user except on a home-directory.

You should almost certainly create a group, add your three users to that group, and then setup permissions based on that group.

BTW, is the application actually creating files in the destination directory, or is it moving them from some other location? When files get moved, within the same volume, then permissions are not updated to what you might expect on the destination, and instead the permissions from the source location are kept.

KB310316: How permissions are handled when you copy and move files and folders

By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.