Link to home
Start Free TrialLog in
Avatar of mbkitmgr
mbkitmgrFlag for Australia

asked on

File Write Access oddity

We have home Folders for all users with security set as per below
  • Bob (Deny Delete this folder, Modify Files and SubFolders contained within)
  • Bob's Supervisor  (Deny Delete this folder, Read only Files and SubFolders contained within)

Bob is not a member of the supervisors group, nor any of the 12 staff who possess a named folder

The conundrum!!!!

  • When Bob creates a file in Word or Excel or even notepad and tries to save the file, a file is created in the folder with the name chosen of zero bytes in size, then generates an access denied error to Bob.  
  • When Bob wants to print to PDF he can save the "printed" output file to his folder without any access denied error.
  • Bob can delete files in the folder.

There are 12 folders being one for each employee and only some have this issue.  I have trolled thru the security on the files and folders and they are all configured identically.
For those affected by this I have deleted and recreated the Named Folder from scratch and get the same outcome.  This also affects the users whether they are logged on via a domain joined PC or Remote Desktop.

What am I missing here?  Please help put me out of my misery!
Avatar of Qlemo
Qlemo
Flag of Germany image

Can you show the exact security descriptor for Bob's folder, please? E.g. the output of icacls.

Your description looks like creating and deleting items in the folder are allowed (folder permission), but file permissions then deny modification of the created file. Applications writing their files in one go are working, those which first create a file to overwrite it don't.
I'll go with Qlemo. Seems security says "write", but not "modify".
Avatar of mbkitmgr

ASKER

Bob who gets the error
D:\Data\Shared Data\Users>icacls "Bob"
Bob             ACME\Bob:(DENY)(D)
                    ACME\GRP_ACME-Care_Supervisor:(DENY)(D)
                    NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                    ACME\ACMEadmin:(OI)(CI)(F)
                    ACME\Bob:(OI)(CI)(M)
                    ACME\GRP_ACME_Supervisor:(OI)(CI)(M)
                    BUILTIN\Administrators:(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

Alice who doesnt
D:\Data\Shared Data\Users>icacls "Alice"
Alice       ACME\AliceW:(DENY)(D)
                ACME\GRP_ACME-Admin_Supervisor:(DENY)(D)
                NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                ACME\ACMEadmin:(OI)(CI)(F)
                ACME\AliceW:(OI)(CI)(M)
                ACME\GRP_ACME-Admin_Supervisor:(OI)(CI)(M)
                BUILTIN\Administrators:(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files
That looks ok that way. Files should be able to get created, changed or deleted, inheriting (M) - which includes R, W, D.
And that works for me. I have created a folder with (Deny)(D) and (OI)(CI)(M) for my user (and nothing else), and can create, overwrite, delete files manually or with NotePad without issues.

Any chance an antivirus is blocking access?
I exported the iCacls to Text for all folders and imported to Excel.

I did find two whose folder permissions that were inconsistent.

BUT I also find that when I:
  1. Choose an affected user
  2. Remove their account from any domain group (i.e ACME-Common-RO)
  3. They suddnely gain the "abilities" as their fellow employees
This only affects accounts that have existed on the domain since its inception (Orginal employees).  Those new to the org on the last 2yrs arent afffected.

I am starting to wonder if there is an issue with a longer term employees GUID that hasnt happened for newer employees
At this stage everything you can think of could be the reason :D
If you reverse the change of removing them from groups by adding them back, does that change anything?
I recall in the days of Server 2000 and Systems Management Server 2.0, we had a client where the users were members of a large number of domain groups.

We found that for some users "abilities" granted by being members of certain groups were not granted.  We lodged a support req with MS Support and found that a buffer used to store information about SMS in AD at the time, was preventing GUID's from growing beyond a certain length.

Microsoft Issued a patch that addressed the issue.  While this is an Server 2008R2 domain, the behaviour is similar
.
Thanks Qlemo, I was pondering what to do next...yours sounds like the way to go
Bingo !!!!

Adding them back into a group fails to change the behavior for longer term employees.

Next step is to delete the user account and re-create the account and see what gives.  My test account is affected so this will become my guinea pig
@mbkitmgr
How many groups do your users have? My users  have quite a few and I hope not to have similar problems in the future as you have.

cheers
Thomas
Each user in this case is a member of 8 groups.

In the situation of Server 2000 the users would be members of up to 70 odd groups

My suspicion is that something about the groups is corrupt
ah...ok..my users go up to 20 groups. so you say if you re-create the user OR the group, give permissions to the folder with that NEW group or user, the problem vanished?
HI Thomas, I realised a few hour after posting the results, they were inconsistent.

Since then I have gone thru all staff to dientify who is/isnt affected.  I identified 3 users - all longer term employees,  After managing their data etc, deleting the accounts and recreating from scratch the issue no longer appears.

I built the domain from new when this org formed, but there was a period of 60 days where they discontinued my services as they felt they had staff who could manage the IT systems in-house which to their surprise didnt go well.
ASKER CERTIFIED SOLUTION
Avatar of mbkitmgr
mbkitmgr
Flag of Australia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial