[SOLVED] Need help with File/Folder permissions

DocGreen

Well-Known Member
Reaction score
44
Location
South Bend, IN
Client asked me to lock down their server and set very specific permissions for folders shared on the network. I thought everything had gone smoothly, but there was one hiccup and I can't explain it.

There's a share named "QC"
Everyone on the network has READ-ONLY access to QC
"Andres" has FULL CONTROL over QC

Here's where it gets screwy...

Andres can not SAVE documents (from within Excel, Word, etc) into the QC folder, and any documents he opens from within that folder open as READ ONLY.

Andres CAN add (drag & drop) and delete files in the QC folder without any problem.

If Andres logs into a different workstation (same username), he can SAVE files (from Excel, Word, etc) into the QC folder without any problem.

It's a Windows Server 2003 Enterprise domain... clients are W7Pro running Office 365.

Here's a snip of the permissions screen:




Andres is the ONLY member of the "QC" security group
Andres is NOT a member of any other group listed in the permissions setting for this folder.

I'm completely stumped here. Please help!
 
On a hunch, I tried SAVING a document to the QC folder from something OTHER than Office... works just fine.

The problem is with Office.
 
At first blush, is it possible that his computer is not opening the office suite using his credentials? Maybe like a "Run As" that is happening, somehow? I wouldn't have expected a problem like that. Weird.
 
Nothing that I can find...


I did install Office using another user's credentials, but I used those same credentials on 2 other PC's that aren't having this problem. (remember I said Andres can save from another workstation just fine).


**Edit**

When I say "another user's credentials" I mean, their Microsoft Account. I only had access to one user's account which I used to download & install Office... but once the users showed up in the morning, they connected their own accounts so they could access their email and whatnot. Again, the problem is only happening on this one workstation, so I don't think it has anything to do with that.
 
Last edited:
Firstly, I would try to setup a dummy folder and set Full Access for your user and see if the same problem persists on the new share.

Secondly, have you tried a reinstall or repair of Office?

This linky looks to be somewhat similar to your issue perhaps.

I have no idea if this will help, but it was linked as an answer to the link above. Disable Opportunistic locking

It would seem there is something specific to that singular client computer, seeing as he can access everything fine from another.
 
Last edited:
Are you 100% certain that particular workstation is properly authenticated in AD? What happens if you login as some other user from that computer?
 
Are you 100% certain that particular workstation is properly authenticated in AD? What happens if you login as some other user from that computer?

I had to give myself permissions to test that, and once I did, I was able to log onto Andres' PC and save office docs to the same folder without any problems. (Andres is the only user that is supposed to have write permissions to that folder)


Since I established that it wasn't his computer specifically that was causing the problem, I tried another approach.
- I completely removed all permissions allowing Andres access to the folder in question. (leaving all the entries for other users' read permissions).
- I removed Andres from the QC security group
- I then re-added Andres to the QC security group
- Then re-set the permissions allowing him full control over the folder
.
.
... no joy.

I'm really confused, seeing as he has no problem on other workstations. At this point I'm entertaining a couple different options:
a.) Create a new user account for Andres
b.) Attempt a complete re-install of office on Andres' computer
c.) Run naked through the streets screaming obscenities

Suggestions? (preferably one that leaves me clothed and not on-site, lol)
 
Here's a little more background information that may or may not help... don't know if any of it will be relevant, but...


- I was on site to upgrade 3 pc's (including Andres') to Win7 Pro (was running Home Prem.) I chose to nuke & pave as it was cheaper than the Anytime Upgrade option.

- Andres doesn't have this issue on the other PC's that were upgraded last night

- While I was working I noticed that Andres' user account didn't match the naming convention they were using. His username was "AndresQC" which was also the name given to his PC. I changed his username to "abahena" to follow the naming convention all the other accounts were using. (this one does concern me a bit)

- The shares on this server aren't setup quite the way I would have done it...



(I have full access to all folders, of course. The only folder Andres seems to have trouble with is the QC folder)
 
Firstly, I would try to setup a dummy folder and set Full Access for your user and see if the same problem persists on the new share.

Secondly, have you tried a reinstall or repair of Office?

This linky looks to be somewhat similar to your issue perhaps.

I have no idea if this will help, but it was linked as an answer to the link above. Disable Opportunistic locking

It would seem there is something specific to that singular client computer, seeing as he can access everything fine from another.



So... I tried your suggestion and created a dummy folder. No problems whatsoever.

Still can't save to the QC folder.
In fact, when I accidentally attempted to overwrite another test file in the QC folder it said that the file was Read Only. I noticed that when looking through the folders on the server... it shows a grayed-out check mark in the "read only" attributes box. I've removed the attribute probably 10 times now, but it keeps coming back.
 
Maybe there is a GPO that is setting that?

Would it be possible to simply rename and copy the CQ folder, create a new CQ folder and work from that? Would be a quick fix if possible.
 
Maybe there is a GPO that is setting that?

Would it be possible to simply rename and copy the CQ folder, create a new CQ folder and work from that? Would be a quick fix if possible.

You know, that may just be the easiest way to do it... but when I copy the files and subfolders from QC, won't they bring the permissions over with them?
 
Solved

I think I just solved the problem.

I was about to try moving everything to a new folder as phaZed suggested... first thing I did was stop sharing the QC folder, and received the message:

There are 1 users connected to QC. If you stop sharing, they will be disconnected.

A light went off. I stopped sharing the folder, then re-created the share with the same folder. Checked from Andres' computer and the problem was gone!

I know exactly which user was still connected. These people have a very bad habit of leaving a bunch of files open overnight. I've told them numerous times that this was a bad practice and would lead to data loss, but they're either too lazy to close them, or don't give a damn. I'm going to their office tomorrow to explain to them how their carelessness caused this problem... question is, should I bill them for my time? I hadn't planned on it because I was assuming I caused the problem.


Thanks for the help guys. Without the brainstorming I probably wouldn't have figured it out. :)
 
You didn't cause the problem. Why you not bill? They're not logging off caused it. And your bill will show them just how expensive that laziness will cost them.
 
Damnit, I just realized as I was creating the invoice... their contract includes free remote support. Guess I should have gone on-site to fix this, LOL.
 
Some thoughts I had...."after the fact" (as it looks like it's working now)

Dunno why the F:\Data root was shared...I don't like sharing from the root, rather start sharing at the first level of folders. BUT...may have something to do with it, depending on how the shortcut was made on that first computer...the one with the symptoms.

Shortcut to \\servername\FData\QC would/could be different than shortcut to \\servername\qc...depending on permissions from that root FData share. Has to do with traversing folders...as a program needs to see available drive space.
Authenticated Users need to be able to traverse/execute/list/read. I learned this recently after troubleshooting a recent project I did with folder redirections (for My Docs)...on a new file server. The issue came up with Adobe Acrobat...which can get wonky with redirected docs...however the issue surfaced because this client needed to save PDFs from their EMR software which was browser based. Got some invalid drive space error. Even though they could copy PDFs to their Docs, create files directly, delete, etc. Users had full control of it. However Adobe I guess runs a bit under system or at least authenticated users...not just under the users account...when another program is calling it up.

So that got me to wondering if the paths to that QC folder were different..specifically perhaps a longer path in your issue...and when you tried it from another computer may you just did \\servername\qc.

Also...(although not the case in your issue since it worked on another computer)...just to double check though, when you "Share" a folder..there are those two levels..I always do the "Share" permission to "Everyone" with full read/write, and then trim the permissions on the Server (NTFS) level.

Another tip..since you mentioned copying the folder and questioning if it would keep buggy permissions with it...copy them to a FAT (FAT 16 or FAT32) partition...and then copy back. FAR partitions will drop (strip) all/any NTFS attributes. It's kind of like putting a file(s)/folder(s) in a washing machine. ;)
 
Just got a call from the client... the problem resurfaced. That has me wondering if it IS a group policy causing the issue. I'm not well versed in GPO's... where would such a setting be hidden?

I'm digging through the GPO editor now, and if I can't find anything, I may just go with Stonecat's washing machine idea, and creating a completely new share. ;)

BTW... should I suggest restructuring their F: drive?
 
Back
Top