From your answer to another post that you are using a Workgroup, the most likely problems are that the user/pswd are different or don't exist on the server, or the user/pswd is not being passed in the correct syntax. In a Workgroup Users are local to each machine, JSmith on the server is not the same as JSmith on the workstation.
A Domain solves both of these issues and has many other advantages if you have more than 4-5 workstations. This is the best solution.
Option 2 is to setup a username and pswd on the server. This can be 1 server user for each wkstn user, 1 server user for each user security group desired: Accounting, Sales, Marketing, etc, or 1 server user for all users. The server username & pswd may, but are not required, to match the username and pswd on the wkstns. Don't use any blank passwords.
Create a batch file on each machine to map the shares as a drive letter and force authentication on the server. Place the batch file in a C:\Admin folder, place a shortcut to the batch file in the All Users Startup folder to have it run on logon, set it to run minimized. The syntax is:
"Net Use X: \Server\Share /User:Server\User Password".
"Net Use /help" will provide more examples.
Net Use X: /del will remove the drive mapping for testing, it will not delete any data.
You can also test authentication against the server with the Net Use command. If the authentication fails with "incorrect user name or password" then either the syntax, username, password or some combination of all 3 are wrong.
Option #2 is not secure and not recommended but could work as a temporary solution.
In the server's Local Security Policy Security Options, add the ACT Log Share name to the "Network access: Shares that can be accessed anonymously" policy. In this case, that would be simply "ACT" (without quotes).
Best Answer
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.exeA 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.