Samba upgrade to 3.2.0 (F9) causes IPv6 problems

[mikebg]

After upgrading to F9 from F8, my samba shares have ceased to be accessible from one remote machine (but not from another remote machine).

This is a result of samba-3.2.0 (as in F9) using IPv6, but I know nothing at all about that, so I am appealing for help!

In my samba log directory (/var/log/samba) I now have files which look like:

__ffff_192.168.1.4.log

The computer with the IP address 192.168.1.4 is called iyonix.bgnet.

In the log file __ffff_192.168.1.4.log I have:

[2008/06/17 17:43:37, 0] lib/util_sock.c:matchname(1670)
matchname: host name/address mismatch: ::ffff:192.168.1.4 != iyonix.bgnet
[2008/06/17 17:43:37, 0] lib/util_sock.c:get_peer_name(1791)
Matchname failed on iyonix.bgnet ::ffff:192.168.1.4
[2008/06/17 17:43:40, 0] lib/util_sock.c:matchname(1670)
matchname: host name/address mismatch: ::ffff:192.168.1.4 != iyonix.bgnet
[2008/06/17 17:43:40, 0] lib/util_sock.c:get_peer_name(1791)
Matchname failed on iyonix.bgnet ::ffff:192.168.1.4

From another machine, mybgpc (192.168.1.5) I can connect, and I get a log entry in its file mybgpc.log as follows:

[2008/06/17 17:44:39, 1] smbd/service.c:make_connection_snum(1188)
mybgpc (::ffff:192.168.1.5) connect to service PCfiles initially as user mybg (uid=500, gid=500) (pid 3376)
[2008/06/17 17:44:43, 1] smbd/service.c:make_connection_snum(1188)
mybgpc (::ffff:192.168.1.5) connect to service Misc initially as user mybg (uid=500, gid=500) (pid 3376)
[2008/06/17 17:44:47, 1] smbd/service.c:make_connection_snum(1188)
mybgpc (::ffff:192.168.1.5) connect to service FamilyPhotos initially as user mybg (uid=500, gid=500) (pid 3376)
[2008/06/17 17:55:01, 1] smbd/service.c:close_cnum(1399)
mybgpc (::ffff:192.168.1.5) closed connection to service Misc
[2008/06/17 17:55:01, 1] smbd/service.c:close_cnum(1399)
mybgpc (::ffff:192.168.1.5) closed connection to service FamilyPhotos

... but I also get a file __ffff_192.168.1.5.log which has:

[2008/06/17 17:44:06, 0] lib/util_sock.c:matchname(1670)
matchname: host name/address mismatch: ::ffff:192.168.1.5 != mybgpc.bgnet
[2008/06/17 17:44:06, 0] lib/util_sock.c:get_peer_name(1791)
Matchname failed on mybgpc.bgnet ::ffff:192.168.1.5

How can I get the matchname stuff to work properly?

I am completely stuck!

[mikebg]

I have found a solution (albeit not 100% perfect).

It is clear that all of the problems result from samba's handling of IPv6. I can see where it happens in the source code, but the cause is, I suspect, something outside of samba which is affecting it when it tries to do reverse DNS. Instead of getting 'iyonix.bgnet' back, it is getting ::ffff:192.168.1.4 .

For the time being, I have removed samba-3.2.0 from my system and built myself a copy of samba-3.0.30 (the fc8 rpm has too many dependencies which clash ...).

This has solved the problem, but I would prefer a cleaner solution!

Any ideas?

[pickman]

I am having problems printing via samba since upgrading from
F7 to F9. I am now convinced that it is because of IPV6 issues. I am also seeing log entries such as you describe. See my original post at:

http://forums.fedoraforum.org/forum/...d.php?t=192136

Thanks for offering one possible solution.

[mikebg]

I am having problems printing via samba since upgrading from
F7 to F9. I am now convinced that it is because of IPV6 issues. I am also seeing log entries such as you describe. See my original post at:

http://forums.fedoraforum.org/forum/...d.php?t=192136

Thanks for offering one possible solution.

Anything new? I recently had an upgrade of samba with yum and found I had to reinstall my copy of samba-3.0.30 to get back my connectivity. Can we really be the only two people having problems?

[pickman]

I successfully turned off ipv6 on all systems, but it did not fix my printing problem. The ultimate solution was to move the printer to another Fedora machine on the LAN. After re-installing the printer, cups, and samba on a different machine, I was able to finally get network printing to work. I never could figure out why it stopped working on the original system after the F9 upgrade.

[mikebg]

Still nothing new? I have tried installing the newer releases of samba but there is nothing I can get working in 3.2.x, so I keep having to reinstall my 3.0 version after yum puts in the latest 3.2 release ... There must be a simple solution to this problem! Developers??

[barry905]

Like you gentlemen, I too am having problems with samba on Fedora 10. I cannot get my newly installed system to logon to my Primary Domain Controller (Fedora 8/Fedora Directory Server). I've isolated the problem to the fact that samba will not accept incoming packets from the PDC, and so users cannot logon. AS far as my needs are concerned, this means that F10 is useless as a domain workstation. I shall have one last install and see if I can get the **** thing to work, but if not it's back to Fedora 8 for me.

[whelm]

I'm experiencing a similar set of problems. I've had unreliable SMB connectivity ever since I set up this F9 server. The box has a long history of different distros and problems. It worked well several years ago, but I won't go into the whole story, other than to say F9 was a clean install.

Connections used to take a very long time to connect or reject. I finally solved that part by finding some stuff in resolv.conf that wasn't correct. But it still doesn't give me connectivity.

I get an XP log in screen and when I fill it in, it just returns immediately. I checked the log file and found a bunch of IP6 type mismatches like described here. I commented out my hosts allow string (I'm wondering if it needs to be in IP6 form these days) and the messages went away, but login still isn't sucessful.

I've spend a whole day working on this and have learned a lot, but its still not working. With log level set to 2 I see it log me in sucessfully anonymously, then:

[2009/02/16 22:06:52, 3] auth/auth_winbind.c:check_winbind_security(54)
check_winbind_security: Not using winbind, requested domain [ESRDSN] was for this SAM.
[2009/02/16 22:06:52, 2] auth/auth.c:check_ntlm_password(318)
check_ntlm_password: Authentication for user [Wilton] -> [Wilton] FAILED with error NT_STATUS_WRONG_PASSWORD
[2009/02/16 22:06:52, 3] smbd/error.c:error_packet_set(61)
error packet at smbd/sesssetup.c(127) cmd=115 (SMBsesssetupX) NT_STATUS_LOGON_FAILURE

I have used smbpasswd as root to set the password again (just in case it wasn't correct or I didn't remember it). It is now known to be the same as the linux login password which works. I'm at a total loss.

Wilton

P.S.: Here's my smb.conf (sans comments)

[global]

workgroup = ESRDSN
security = user
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
; template shell = /bin/false
winbind use default domain = false
winbind offline logon = false
read only = no

netbios name = LXSERVE

server string = LxServe


; interfaces = lo eth0 192.168.12.2/24 192.168.13.2/24
; hosts allow = 192.168.0. 127.0.0.1


log file = /var/log/samba/log.%m
max log size = 50
log level = 2

passdb backend = tdbsam


domain master = yes
domain logons = yes

; local master = no
os level = 33
preferred master = yes


wins support = yes
; wins server = w.x.y.z
; wins proxy = yes

dns proxy = no

; load printers = yes
cups options = raw

printcap name = /etc/printcap
printing = cups

username map = /etc/samba/smbusers
; encrypt passwords = yes
guest ok = yes
; guest account = nobody
; store dos attributes = yes

[homes]
comment = Home Directories
browseable = no
writable = yes
; valid users = %S
; valid users = MYDOMAIN\%S

[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
guest ok = yes
; writable = No
printable = yes

[wilton]
comment = wilton on LxServ
path = /home/wilton
writeable = Yes
; browseable = yes
valid users = wilton

[ESR]
comment = ESR on LxServ
path = /home/ESR
writeable = yes
; browseable = yes
valid users = wilton

[whelm]

OK, I seem to have resolved this problem on my machine. Here is what I have found for anyone else that is needing it.

Many problems with Samba aren't Samba problems at all, they are underlying network related problems. As mentioned in my previous post, a large delay in client responses turned out to be related to wrong information in resolv.conf.

My underlying problem was domain related. The server is serving a web page under the name www.esrdsn.com, which is mapped to my one and only public IP address. The computer itself is behind a rounter on a LAN with a 192.168.0 class C IP address. Thinking I was doing the right thing, I named the workgroup esrdsn, like the web page, and identified the server's domain as esrdsn.com and its full local name as lxserve.esrdsn.com. The problem is that internet DNS servers know esrdsn by a public IP and the computer is actually on a private LAN. So a DNS lookup of esrdsn.com is going to return an IP address that will only reach the computer for port 80 (www) traffic (which the router forwards). Anything else (Samba?) will fail resulting in mismatches.

The solution in this case was to remove the domain name from resolv.conf (the LAN doesn't really even need a domain name), put only the computer name (lxserve) in hosts, and change the workgroup name to something different in all the affected computers--no more problem.

Wilton

[mwhidby]

One solution to the name mismatch errors (e.g. matchname: host name/address mismatch: ::ffff:192.168.1.5 != mybgpc.bgnet) is to disable IPv6. This is quite easily done by creating a file in /etc/modprobe.d - you can call it what you like but a helpful name like "disable-ipv6" is useful. The contents of this should read:-

install ipv6 /bin/true

After a reboot, IPv6 will be disabled and you shouldn't get any mismatch error messages if you enable the "allow hosts" entries in your samba configuration. Bug? Feature? Who knows...

[whelm]

Very interesting on several accounts:

1. This seems to imply that the problem is IP6 related which is why I and others didn't notice it before.

2. Is it a bug in the IP6 implementation (on F9/10) or a designed in "feature" of IP6?

3. Supposedly IP6 is disabled on this machine. I have already forgotten what I looked at, but I disabled it when I installed F9 and I did check to see if it was disabled. However, it appears that there may be various levels of being disabled, as I was getting mismatch messages against IP6 addresses, and there were other indications that at least some IP6 related code was being executed.

Wilton

[SlowJet]

I'm running F10 (with allll the updates)
and F11 (Beta by tomorrow)

and I don't have any of those problems.

$#@
1234

Youv'e got to know when to hold 'em,
know when to fold 'em,
known when to walk away,
from the bugs of
Yesssssss Terrrrrrrr DAYYYYYYYYY! Yeh

SJ

Youth is wasted on the young.

[ploink]

I think the problem is not ipv6 related, but due to a dns problem.
The same hostname must resolve to the same ip address on both client and server.

For example, there may be a different ip specified in one of the hosts files.
Or, you may be running your own internal nameserver with a private domain and the client is told to use another, external dns.

I am unable to test this at the moment, since I do not have access to those clients from here, but I know some are configured to use an external dns...

[markdk]

I'm having the same sort of issues with FC10. I don't have a solution but perhaps a different angle. I'm not trying to connect a windows server to samba, but a FC10 client to an FC10 server, both servers are setup to allow ipv6.

On the server I'm getting the
May 6 19:54:14 falcon smbd[31759]: Matchname failed on eagle-private ::ffff:169.254.218.186

On the client I'm getting
[mark@eagle ~]$ smbclient -N -L falcon-private
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.2.11-0.30.fc10]

Sharename Type Comment
--------- ---- -------
WinXP Disk WinXP Backup Drive
eagle Disk Eagle Backup Drive
osprey Disk Eagle Backup Drive
firebird Disk Firebird Backup Drive
IPC$ IPC IPC Service (Samba Server Version 3.2.11-0.30.fc10)
timeout connecting to 169.254.218.183:139
Connection to falcon-private failed (Error NT_STATUS_ACCESS_DENIED)
NetBIOS over TCP disabled -- no workgroup available

All my servers use hosts files, no DNS. Although all the hosts files only contain ipV4 entries. I have tried adding various entries to match with no joy.

However I'm not sure where it's getting the ffff:169.254.218.183 from. I have noticed in my setup where the 169 address is a second alias on a single ethernet card ifcfg tells me eth0 has an inet6 addr of fe80::20c:6eff:fe63:c7a2/64 which is nothing like the 192.168.1 address it lives on, eth0:1 I am trying to use for the samba connection has no inet6 addr assigned so I guess it just gets ffff shoved on the front ???.


-- Anyway --
it certainly seems to be a reverse lookup problem of some sort. The Matchname failed is consistent whenever I try to connect to samba from any of my other linux servers (it's not a windows client only problem) .

When I run the same command above on the FC10 server running the samba server, it just works. It should be noted I have no ipv6 entries in the hosts file on the samba server either, it just works ok there.

[mark@falcon ~]$ smbclient -N -L falcon-private
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.2.11-0.30.fc10]

Sharename Type Comment
--------- ---- -------
WinXP Disk WinXP Backup Drive
eagle Disk Eagle Backup Drive
osprey Disk Eagle Backup Drive
firebird Disk Firebird Backup Drive
IPC$ IPC IPC Service (Samba Server Version 3.2.11-0.30.fc10)
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.2.11-0.30.fc10]

Server Comment
--------- -------
FALCON Samba Server Version 3.2.11-0.30.fc10

Workgroup Master
--------- -------
WORKGROUP FALCON
[mark@falcon ~]$

I don't want to disable ipv6 so am also curious about any possible solution.

[ploink]

Solved the problem!
I made a few tweaks in smb.conf that got rid of the errors. Im not sure which tweak is responsible, so I list them here:

--
interfaces = lo br0
bind interfaces only = true

Interface br0 is my bridge interface, that holds members eth0 to eth2. I added the "bind interfaces only" to make sure that samba won't listen on them individually.

--
hosts allow = 10. 127.

Oops, I had forgotten to allow localhost (127.)... You may also remove this line completely if you trust your network.

--
oplocks = False

Probably has nothing to do with this problem, but it solved some client caching problem on another server so I added it to this one too. Makes connections more reliable at a little performance expense (probably not noticeable on todays fast networks).

--
smb ports = 139

This will remove port 445 support. Should work if you are not using Active Directory.
Gets rid of errors like "getpeername failed. Error was Transport endpoint is not connected". see http://forums.gentoo.org/viewtopic-t-304678.html