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.
I found the solution. See: http://support.microsoft.com/kb/947232
Cause:
By default, Windows Vista and newer versions of Windows prevent local
accounts from accessing administrative shares through the network.
I know it says "Vista", but Windows Server 2008 seems to be affected by it. By going into my Windows Server 2008 machine and adding a new DWORD registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy" and setting it to 1, the default administrative share as well as the USB drive root share both become accessible from my Windows 7 machine on the network.
Explanation:
0 = build a filtered token
This is the default value. The administrator credentials are removed. These credentials are required for remote administration of the print drivers.
1 = build an elevated token
This value enables the remote administration of the print drivers on a server within a workgroup.
Best Answer
You can only give permissions on Security Groups, double check that you haven't created a Distribution Group (you can see that in the group's properties, under "Group type").
Then, don't forget that you must logoff and logon again on the client before the group membership is effective. If you logon as User1 on PC1, and then you add User1 to Group1 in Active Directory, you have to logoff/logon again on PC1 with User1 before the group membership is effective.
Take a look at the "Effective Access" tab in the advanced Security Options of the folder, you will be able to choose a username and ask Windows to check if the user has access or not, and eventually why the access is denied.