Start Free Trial

asked on

Windows Server 2003 - Users cannot rename files/folders

I just installed a new Windows Server 2003 and have hit what appears to be a permissions problem. Users can login and access the shares but no files\folders can be renamed. The following settings are in effect:

- All shares are set for Full Control for Everyone.

- Initially, NTFS permissions were setup for each user to have appropriate control. While testing, I have tried to grant full access to everyone but, so far, I have not been able to allow anyone (even Administrators) to rename files/folders.

- Files and folders can be deleted without problem.

Additional Symptoms

- After attemtping to rename a file, that item is completely locked for some time period (probably 30 mintutes but I have not timed the release of the lock). By completely locked, I mean that the server believes that the file is exclusively opened (no read access, no copying, etc.). The file does not show open in the File Server and force closing the containing folder makes no difference. The file cannot be changed even if Administrator is logged into the server itself.

- When the rename fails, sometimes you get an error message but recently, there has been no message. It takes 1-2 minutes for the attempt to timeout and then the file is locked (see above).

- I tried installing the new group policy management utility but that caused Active Directory to die (corrupt DB, could not reboot server). I was forced to reinstall the AD files from a backup. (same problem before and after the restore)

- Running the AD integrity check reported no errors.

- Applications that use the save temp/delete/rename (or similar) saving method do not work. The temp file is saved but is not deleted (e.g. Excel) and the original file is not changed. Apps that save directly to the file appear to work normally (e.g. Notepad and Access).

- This is brand-new server. All shares reside on a partioned SATA RAID5. The OS is also installed on the RAID. All patches and updates have been applied. The server is an HP dual Xenon 3GHz with 2Gb RAM (1Gb failover).

- Most of the folders were copied from a previous "server" (XP Pro) but even new folders exhibit the same problem.

- I have nothing in the event logs that appears to be related.

Is there any "Deny" permissions ticked for the everyone group on the folders? A deny permission will override ALL other permissions granted.

ASKER

No, there are no Deny permissions. And, Effective Permissions shows complete control (for my principal test case).

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

1 - Assuming that no one has attempted a rename from a share, the local machine is able to rename files/folders without a problem. The problem only occurs after a rename attempt from a remote computer via a share.

2 - I wasn't aware of this utility. Thanks. If I'm understanding it correctly, the test folder is open by "system". No other process is listed as having this fodler open. I also notice that several (4) of the files inside the test folder are considered open as well (they were never opened explicitly). It appears that something is not releasing the handle but the process "system" is too generic. Is there a way to determine which thread has the handle?

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

These are great utilities. I'll have to spend more time looking at this company.

Here is what I have found so far:

AccessEnum - The root of the shared volume shows everyone read/write. The specific shares in question are not listed. I assume this is due to them having the same permissions as the root.

ShareEnum - Running this utility on the server (as Administrator) results in zero data; no shares on the server or any other machine. Running it on my machine shows all shares and the shares in question all show everyone read/write.

FileMon - Using a share to create a new folder and give it name: No data is displayed for the directory in question (F:\Users\Rob shared as \\server2\users). However, there are quite a few references to the root of the share volume (F:\). In some cases (I can't say for sure all), there are a number of lookups in localpolicies after the references to F:\. Performing the same test via the local file system shows quite a bit of activity. In all cases, every action is reported as SUCCESS.

Other than process explorer try utilities mentioned by Tolomir.

I would still suggest, try disabling file & sharing shaing fully, reboot and then enable it again. This wil reset permissions on all folders.

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

The Advanced mode does give quite a bit more information. There are a few errors shown below with the surrounding activity (you may need to paste this into a new file to format it correctly):

12:44:45.578 PM      System:4      IRP_MJ_CREATE       F:\Users\rob\New Folder      NOT FOUND      Options: Open Access: All
12:44:45.578 PM      System:4      IRP_MJ_CREATE       F:\Users\rob\New Folder      SUCCESS      Options: Create Directory Access: All
12:44:45.578 PM      explorer.exe:4572      IRP_MJ_DIRECTORY_CONTROL      F:\Users\Rob            Change Notify
12:44:45.578 PM      System:4      FASTIO_QUERY_NETWORK_OPEN_INFO      F:\Users\rob\New Folder      FAILURE
12:44:45.578 PM      System:4      FASTIO_QUERY_BASIC_INFO      F:\Users\rob\New Folder      SUCCESS      Attributes: D
12:44:45.578 PM      System:4      FASTIO_QUERY_STANDARD_INFO      F:\Users\rob\New Folder      SUCCESS      Length: 0
12:44:45.578 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users\rob\New Folder      SUCCESS      FileEaInformation
12:44:45.578 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users\rob\New Folder      SUCCESS      FileStreamInformation
12:44:45.578 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users\rob\New Folder      SUCCESS      FileAttributeTagInformation
12:44:45.578 PM      System:4      IRP_MJ_QUERY_SECURITY      F:\Users\rob\New Folder      BUFFER OVERFLOW
12:44:45.578 PM      System:4      IRP_MJ_QUERY_SECURITY      F:\Users\rob\New Folder      SUCCESS
12:44:45.578 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users\rob\New Folder      SUCCESS      FileInternalInformation
12:44:45.578 PM      System:4      IRP_MJ_CLEANUP      F:\Users\rob\New Folder      SUCCESS
12:44:45.578 PM      System:4      IRP_MJ_CLOSE       F:\Users\rob\New Folder      SUCCESS

12:44:46.671 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users      SUCCESS      FileNameInformation
12:44:46.671 PM      System:4      IRP_MJ_CREATE       F:\Users\rob\New Folder      IS DIRECTORY      Options: Open Access: All
12:44:46.671 PM      System:4      FSCTL_REQUEST_BATCH_OPLOCK      F:\Users\rob\New Folder      INVALID PARAMETER
12:44:46.671 PM      System:4      FSCTL_REQUEST_OPLOCK_LEVEL_2      F:\Users\rob\New Folder      INVALID PARAMETER
12:44:46.671 PM      System:4      FASTIO_QUERY_NETWORK_OPEN_INFO      F:\Users\rob\New Folder      FAILURE
12:44:46.671 PM      System:4      FASTIO_QUERY_BASIC_INFO      F:\Users\rob\New Folder      SUCCESS      Attributes: D
12:44:46.671 PM      System:4      FASTIO_QUERY_STANDARD_INFO      F:\Users\rob\New Folder      SUCCESS      Length: 0
12:44:46.671 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users\rob\New Folder      SUCCESS      FileEaInformation
12:44:46.671 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users\rob\New Folder      SUCCESS      FileStreamInformation
12:44:46.671 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users\rob\New Folder      SUCCESS      FileAttributeTagInformation
12:44:46.671 PM      System:4      IRP_MJ_QUERY_SECURITY      F:\Users\rob\New Folder      BUFFER OVERFLOW
12:44:46.671 PM      System:4      IRP_MJ_QUERY_SECURITY      F:\Users\rob\New Folder      SUCCESS
12:44:46.671 PM      System:4      IRP_MJ_CLEANUP      F:\Users\rob\New Folder      SUCCESS
12:44:46.671 PM      System:4      IRP_MJ_CLOSE       F:\Users\rob\New Folder      SUCCESS

12:44:46.671 PM      System:4      IRP_MJ_CREATE       F:\Users\rob\New Folder      SUCCESS      Options: Open Access: All
12:44:46.671 PM      System:4      FSCTL_REQUEST_BATCH_OPLOCK      F:\Users\rob\New Folder      INVALID PARAMETER
12:44:46.671 PM      System:4      FASTIO_QUERY_NETWORK_OPEN_INFO      F:\Users\rob\New Folder      FAILURE
12:44:46.671 PM      System:4      FASTIO_QUERY_BASIC_INFO      F:\Users\rob\New Folder      SUCCESS      Attributes: D
12:44:46.671 PM      System:4      FASTIO_QUERY_STANDARD_INFO      F:\Users\rob\New Folder      SUCCESS      Length: 0
12:44:46.671 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users\rob\New Folder      SUCCESS      FileEaInformation
12:44:46.671 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users\rob\New Folder      SUCCESS      FileStreamInformation
12:44:46.671 PM      System:4      IRP_MJ_QUERY_INFORMATION      F:\Users\rob\New Folder      SUCCESS      FileAttributeTagInformation
12:44:46.671 PM      System:4      IRP_MJ_QUERY_SECURITY      F:\Users\rob\New Folder      BUFFER OVERFLOW
12:44:46.671 PM      System:4      IRP_MJ_QUERY_SECURITY      F:\Users\rob\New Folder      SUCCESS
12:44:46.671 PM      System:4      FSCTL_GET_REPARSE_POINT      F:\Users\rob\New Folder      NOT REPARSE POINT
12:44:46.671 PM      System:4      IRP_MJ_CLEANUP      F:\Users\rob\New Folder      SUCCESS
12:44:46.671 PM      System:4      IRP_MJ_CLOSE       F:\Users\rob\New Folder      SUCCESS

The end of the log, when the failure is reported, shows only success (probably a timeout condition).

ASKER

I'm only guessing but, based on the security request buffer overflows, this seems to point to a corrupt Active Directory. Does this sound right? If so, how can it be corrected?

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

OT: This is funny, all blame Linux for being so complicated, but in case you have to repair your system, even "the great" windows is down to the command line... </OT>

Tolomir

ASKER

I'll look at it more closely but this is the first tool we ran. The integrity check reported no problems.

ASKER

The only option, other than the integrity check, that looks useful for this problem is the soft recovery option. Of course, to try it I'll have to bring the server down.

Since I can't do this until tomorrow, do you have any other thoughts?

about that part:

> - After attempting to rename a file, that item is completely locked for some time period (probably 30 mintutes but I have not timed the release of > the lock). By completely locked, I mean that the server believes that the file is exclusively opened (no read access, no copying, etc.). The file
> does not show open in the File Server and force closing the containing folder makes no difference. The file cannot be changed even if
> Administrator is logged into the server itself.

Would be interesting to see what filemon produces as error messages...

--
Apart from that I'm a bit lost too...

Tolomir

> - I tried installing the new group policy management utility but that caused Active Directory to die (corrupt DB, could not reboot server). I
> was forced to reinstall the AD files from a backup. (same problem before and after the restore)

But I guess this is the main issue....

So the soft recovery should be a good option...

ASKER

I spent some more time analyzing the Filemon log and I don't believe that any of the entries are actually errors. The buffer overflows appear to be normal buffer size requests and the failure on the fastio queries appears to be a check to see if the file is already open (that's a guess since I haven't found any reliable information either way).

I'm still planning to test the AD but...

Indeed error messages like buffer overflows are normal, actually I don't know if that is a real windows problem or just a cosmetic "feature".

Filemon is of cause no newbie tool, but since it just logs events, no real danger to the system either...

ASKER

A standard method of getting the buffer size when the size is variable is to pass a 0 during the first call (which will return the actual value) and then use that value to create a buffer of the correct size. I just didn't think that anyone would log that as a buffer overflow.

ASKER

I noticed a few references in Filemon to gpt.ini errors. So, I turned on monitoing and retried the test:

USERENV(5a8.13b0) 15:40:24:093 GetGPOInfo: Local GPO's gpt.ini is not accessible, assuming default state.
USERENV(5a8.13b0) 15:40:24:093 GetGPOInfo: Leaving with 1
USERENV(5a8.13b0) 15:40:24:093 GetGPOInfo: ********************************
USERENV(5a8.13b0) 15:40:24:093 ProcessGPOs: Logging Data for Target <SERVER2>.
USERENV(5a8.13b0) 15:40:24:093 ProcessGPOs: OpenThreadToken failed with error 1008, assuming thread is not impersonating

Have you checked the "Current Owner" settings?

ASKER

The volume's owner is Administrators <- note the "s"
The share's owner is Administrator

ASKER

I ran ntdsutil using files:integrity & recover and the Semantic Analysis tools. No problems found.

I would try resetting the owners and permissions on all the subfolders and files.

ASKER

What is the best way to do this? We've deleted and changed permissions quite a bit trying to figure this out. Is there a way to wipe out all permissions and start over? I've tried creating a brand new share (even on a seperate volume) and had the exact same problems.

best way to reset permission is to disable file sharing and re-enable it.

ASKER

I was hoping for a way to test one share without resetting everything. Unfortunately, this is a production server and it can be difficult to find a time when the shares are not in use. Is there anyway to do this or will I just have to bite the bullet?

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

I reapplied the settings as suggested starting at the volume the shares are located on. The permissions were correctly reset to everyone with full access. I then applied the more restrictive settings to one of the shared folders and then opened up the permissions for each users folder. Everything appear to be working.

I now need to apply the same changes to the remaining shares to verify that the fix is complete.

ASKER

This issue appears to be closed.

Unfortunately, complete testing was not done prior to apply the pemissions changes sugegsted by kclause. That is, I don't know if the ntdsutil was responsible for the corrections of if the permissions changes themselves were the key.

The ntdsutil indicated that it did not find any issues but also indicated that the it made some changes. Of course, it reported the exact same results everytime I ran the tests so I don't know if any changes were applied or not.

On the permissions side, I thought I had performed this same correction a while back without any change. If the permissions change was responsible then I must have done something differently.

It is also possible that both fixes worked together to correct the issue. Since I cannot determine which one one was the final answer, I believe that the EE protocl is to split the points. How do I do that?

Thanks to everyone for your help.