I have an end user that has trouble moving folders within a Windows Server 2008 network share.
They receive an error most of the time as per the screenshot, then only a few seconds later they will move the folder ok.
They have Full Control access to the network share and all subfolders.
On the workstation nothing of note is logged into the Event Viewer under Application and System, however "Audit Success" logs appear matched to this issue under Security.
Can someone please help?!
The file is being used!? Since your screenshot is from Windows server 2008 or 2008 R2, I will hazard that you are trying to move files from an NTFS filesystem and not a DFS share or from a network folder.
If the file is being used, determine the process that has the open handle, and then close that process.
Depending on how the file is opened (for example, it is open for exclusive access instead of shared access), you may not be able to delete a file that is in use. You can use a variety of tools to help you determine the processes that have open handles to files whenever you want.
The symptoms of this issue may vary. You may be able to use the Delete command to delete a file, but the file is not actually deleted until the process that has the file open releases the file. Additionally, you may not be able to access the Security dialog box for a file that is pending deletion. To resolve this issue, determine the process that has the open handle, and then close that process.
To find the process, use the the Process Explorer tool from Windows SysInternals.
procexp.exe
A little disclaimer here, closing handles might cause data inconsistency, loss and/or other undesirable effects. Make sure you understand what you’re doing before you do it.
=============================================================================
Cause 1: The file uses an ACL You may not be able to delete a file if the file uses an Access Control List (ACL). To resolve this issue, change the permissions on the file. You may have to take ownership of the files to be able to change the permissions.
Administrators have the implicit ability to take ownership of any file even if they have not been explicitly granted any permission to the file. File owners have the implicit ability to modify file permissions even if they are not explicitly granted any permissions to the file. Therefore, you may have to take ownership of a file, give yourself permissions to delete the file, and then delete the file. You cannot use certain security tools to display or to modify permissions because the file has a non-canonical ACL To work around this issue, use another tool (for example, a later build of Cacls.exe).
The Access Control Entries (ACEs) in an ACL have a certain preferred sequence depending on their type. For example, ACEs that deny access typically come before ACEs that grant access. However, nothing prevents a program from writing an ACL that has ACEs in any arbitrary sequence. In some earlier versions of Windows, issues occurred when Microsoft Windows tried to read these "non-canonical" ACLs. Sometimes, you cannot modify these ACLs correctly by using the Microsoft Windows Explorer graphical security editor. This issue has been corrected in later versions of Windows. If you are experiencing this issue, use the most recent version of Cacls.exe. Even if you cannot display or edit an ACL in place, you can write a new ACL that lets you to gain access to the file.
I would guess that the user has thumbnails enabled in Windows Explorer > Folder Options > View, and that the Thumbs.db file it creates is preventing the directories from being deleted. After not viewing the affected folder for a short timeout, the Thumbs.db file is automatically released from memory, and the folder can be deleted. Latency issues between client and file server can trigger this problem, although I do not know the root cause.
Enabling the option to Always show icons, never thumbnails should provide a workaround.
