# Samba 3.5.6_2 Issues



## ckozler (May 4, 2011)

Hey Guys,

I hope this is something very stupidly simple but I have wrecked my brain for the last week trying to figure this out.

To give a little background information:

- I have a desktop with FreeBSD 8.2-current running.  I also have a genuine vanilla install of Windows 7 Ultimate.  From the FreeBSD desktop I have Samba exporting a number of shares to my Windows machine.  I have dictated only valid users (e.g.: authenticated users) can access the shares and this is OK and works.  I have left all of the default configuration except for appending my shares to the end of it and restarting Samba for the changes to take affect

I am trying to configure a server now to be an off-site file backup for the office users.  This is a Dell 1950 server with two drives in a Gmirror RAID1.  I have installed the *exact same port with exact same compile options* and have also made the necessary changes to Samba to export a share.  No matter what I do, the Windows 7 Machine returns an "Access Denied".

The part that is making me wreck my brain is that these are two *identical* installs and configurations of Samba 3.5.6_2 but I am seeing different logs on client connections and different error messages that should not be happening.

On my FreeBSD desktop I have my "homes" share which is the default share that Samba comes exporting (it does not actually specify a path) along with a number of others.  I can run *net view \\the_ip* on my Windows machine to view all shares that the server is sharing and can see ones that users are not even authenticated to (which is OK that they can see the list).

When I try to execute this on the server Samba instance, I am returned with "Access Denied".  When I add the Samba configuration for 
	
	



```
map to guest = Bad Password
```
 I am able to browse the shares (not what I really want but doable I guess).  When I add a user the *exact same way* as I did on my FreeBSD desktop, I am still returned with access denied.  

The very odd part I see is that the Samba log on the server calls *check_ntlpm_password* or something like that whereas the desktop is not.  I have successfully added and enabled the user with *smbpasswd* (I am OK with managing two separate UNIX passwords and Samba passwords)

I have searched for days to see if there has been any patch releases to which this could have affected this latest install but nothing comes up.

Can anyone provide any help?


----------



## ckozler (May 4, 2011)

Correction, when I add the Samba configuration for map to guest I am able to run *net view \\the_server_ip* and see all of the shares.


----------



## ckozler (May 4, 2011)

Hm..I changed a policy on Windows 7 but it doesn't make sense as to why I had to do for the FreeBSD server instance and not my desktop instance.  I still don't want to mark this solved yet.


----------



## SirDice (May 4, 2011)

After you've made changes to samba be sure to check on the Windows machine the IPC$ connection is also removed. If you don't it will use the previous session which failed.

Have a look with [cmd=]net use[/cmd] and remove any IPC$ connection to your server before trying to connect again.


----------



## ckozler (May 4, 2011)

SirDice said:
			
		

> After you've made changes to samba be sure to check on the Windows machine the IPC$ connection is also removed. If you don't it will use the previous session which failed.
> 
> Have a look with [cmd=]net use[/cmd] and remove any IPC$ connection to your server before trying to connect again.



Will do. I am going to keep looking into this as it appears that on the FreeBSD server Samba installation I can only connect when I have the parameter 
	
	



```
map to guest = Bad Password
```
 Other than that, it consistently fails.

My biggest baffling is why these are the exact same installations and exact same configurations yet the server requires the extra parameter.

I also enabled swat on both of the hosts (desktop and server) and did a *diff* on a full view of the configs and only minor changes (eg: workgroup name) were different.


@DutchDaemon - Sorry...I wasnt able to edit my posts but I can now.


----------

