Common causes:

• Lack of network connectivity.
• Forgot password
• Multiple unsuccessful logins caused lockout
• User changed password on one PC; 2nd PC elsewhere trying to access account resources using old password (can be exciting)

Without a network connection it may stil lbe possible to login to a PC, but when the machine tries to map drives, that action will fail. If a user has not logged into the PC before, the initial login will fail if there is no network connection.

Is the PC on the network?

Check to see if it is plugged into a network socket, or into a switch;

see if the switch is connected to a network drop. Is the switch plugged in.

User forgot password.

User didn't realize that the UNIX amd Windows passwords are different, changed their UNIX password, and then got rid of their password sheet.

Solution is to reset the user's password. Don't let them pick a password, set one for them.

A user trying to login too many times incorrectly will be locked out. See resetting samba passwords.

This is a complicated one, and involves users that login or access their shared directory (or directories) from multiple locations. Perhaps the user has given his/her password to a second person for the purpose of sharing files for collaboration.

The user changes their password and is subsequently locked out. Sequence of events:

• User changes password. Good!
• Unfortunately, the second machine will continue to try to access the user's account/homedir/etc using the user's older password. This will cause multiple login attempts to accumulate rapidly, which will lock the user out of his own account soon after the password change.
• it looks like a password cracking attack!

Logging the user out of his own machine should be done, and then logfiles searched to locate the machine which will still be pounding away trying to access the unreachable resource.

Logfiles are located on cs.wpi.edu:/var/log/samba and on csshare:/var/log/samba . There will be many hundreds of files in each of these two directories, but if the “attack” is currently happening, only a relatively small number of files, the most recent ones in each of those two directories will need to be searched for evidence of the failed login.

A useful command to run in each directory might be:

  egrep -B1 'username.*FAIL' `find . -type f -mmin -15 -print|xargs` | less

You should of course replace “username” with the name of the user that is having the problem.

Once you've used the logfiles to locate the mahcine where the bad logins are coming from, that machine should be unplugged from the network in order to stabilize the situation. Then unlock the user's account and get him/her logged in and happy.

On the unplugged machine, UNMAP the share that is causing the trouble, then log out the account that is logged in. Reboot the machine and connect it to the network. Hopefulyl the problem will he solved now, unless there are multiple machines making bad requests…