Windows Server 2008 R2 SP1 - Windows 7 SP1 - Folder located on server, normally accessed via drive letter
There is one folder on the network where all users have modify rights. Suddenly people are not able to rename folders anymore. They can create new ones, do everything according to their permissions within them and existing ones but rename isn't possible anymore. The error message says they are in use, which they aren't, I did several tests. No file on the server had a lock count while testing. Even directly on the server with the administrator account I can't do it.
There is one exception: I used KB article 2025703 which advised to enable "Turn off the caching of thumbnail pictures" on individual machines. This has worked on my machine (assuming it was what solved it) but not on others. I rolled out the setting through GPO (did a few checks around the office with Resultant Set Of Policy). I also set "Turn off caching of thumbnail pictures".
To make sure it is about renaming I tested it both in Explorer, from the command prompt and from the PowerShell prompt. Same result.
It seems not to have to do with anything locked as it happens with empty directories that were just created. Even when clicking New Folder in Explorer (which seems to create a folder called New Folder which is immediately offer for renaming) you cannot change the name.
To summarize, this happens when accessing the folder through: - Drive letter - UNC path - Directly on the server On only one PC I got it working again (for any tested account) after enabling the "hidden thumbs.db files" setting, which had no effect on other machines.
At this point I have no clue. What I find says "Unlock files". I cannot find any locked files and it this scenario it doesn't seem to have any meaning.
Edit 2013-12-6: I did several attempts to find unlocked files, I found none. The problem persists. One colleague reported his virtual XP could do it while its Windows 7 host could not. So there are 2 PCs that can rename regardless of who logs on, and the rest can't, also regardless of who logs on.