You'd also need to make sure that the Samba is trying to connect to the same workgroup/domain as the Windows shares are on. That's just about the first option in /etc/samba/smb.conf (and the one most often completely wrong).
Second, if you're trying to view Windows shares from the Linux box,
smbpasswd is not as urgent as that the user trying to connect to the Windows box being known to the Windows box.
Basically
smbpasswd serves the same function for the Linux Samba
server (which means if the Linux box is not sharing files, there is no Linux Samba server running), as the administrative add user function does for the
Windows Samba server... and that function is to identify what username/passwords are allowed to view files shared by that server.
So to view files on a Windows box (shares served by the Windows Samba server, which is installed by default), the admin of the XP box must add "the user" (or "
a user", it does not necessarily have to be the same u/p as the unix user, as you only need to enter an
authorized u/p in the dialog) to the userlist, or the shares must be set to "Everybody", and/or "guest access" must be enabled.
Which last two options are a bit too insecure for my taste, so the shares on the Windows box are limited to specific users, one of whom is my former Windows user when I was accessing the shares from a dual-boot setup which no longer exists, but one could just as easily make a "junk" user on the Windows box who had only the rights necessary to access the share (although, under Windows, that still gives you a lot of unnecessary rights by default to act on Windows system files that cannot be well "locked down" short of a Policy edit).
For the Windows box to access shared files on the Linux box, one must first have the Samba server component installed, and then must share some files (or rather, a folder containing some files). That part can get a bit tricky, as Linux enforces user privileges much more firmly (and correctly) than Windows does, so the Linux user wanting to share files is limited as to where those files must reside in order for 1) him/her to have the right to give access to others to read or modify the shared folder/files (for example, user "joe" does not have the right to change access permissions on the /etc/ folder, so cannot share it); and 2) for the sharing users to have reasonably easy access to the folder in the first place (folders in /mnt, for example, may only be readable by members of certain groups, and "others"-- which may include the Windows user trying to see the share-- may not have even read permissions. That doesn't help anyway if the shared folder needs to be read-write for all authorized users). This is why shares are generally restricted to the /home folder and more specifically usually to one's own /home/username folder (although one may of course mount a whole shared partition to /home/username/somefolder if one so desires).
Once that hurdle is overcome, the "outside" user must be made known to the Samba servers as an authorized user via the use of
smbpasswd as above, after which the Windows box should, theoretically, be able to view and access any shares from the Linux box. In practice, it is generally not so cut-and-dried, but certainly can be made to work with a bit of effort, as well as tools like Webmin, and Samba-Swat for configuration, and LinNeighborhood, Nautilus or Konqueror's smb browsers, or Smb4k for viewing, mounting and unmounting shares from the Windows box to you.
It's mostly complex because it's often hard to know where and when authentication is failing, and it's often hard to know who's authenticated on the Windows box, to do what, and where their authentication is kept.
But reading
The Official Samba-3 HOWTO and Reference Guide can help you understand the issues involved and set Samba up correctly, as can reading
rute in general, and in particular
39. smbd -- Samba NT Server.
Hope this helps; you've been very non-specific as to just what is not working with your Samba setup and where access is falling down.