From our Debian user: Hi. It took me quite some time to figure out what the cause was: /sbin/mount.cifs //server/share mointpoint --verbose -o user=username,noperm parsing options: user=username,noperm Password: mount.cifs kernel mount options unc=//server\share,pass=******,ver=1,user=username,noperm,uid=1024,gid=100 mount error(22): Invalid argument Now 'server' has an ipv4 and an ipv6 address. If I pass options -o user=user,ip=servername,noperm the same error 22 is risen. If I pass options -o user=user,ip=ipv4-address-of-server,noperm the mount is successfull. I didn't test if this is just ipv6 related, or just happens if a server has multiple Address records. This does not happen with mount.cifs from etch (samba 3.0.24) or lenny (samba 3.2.5), then only the ipv4 address is being tried and it works without specifying an ip= option.
I tried this and mount failed. # mount -t cifs //cifstest8/smb8 /mnt/smb_a --verbose -o ip=fe80::214:5eff:fefb:3f7c,noperm,user=root,pass=password parsing options: rw,ip=fe80::214:5eff:fefb:3f7c,noperm,user=root,pass=password ip address fe80::214:5eff:fefb:3f7c override specified ip address specified explicitly mount.cifs kernel mount options unc=//cifstest8\smb8,ver=1,rw,ip=fe80::214:5eff:fefb:3f7c,noperm,user=root,pass=root mount error 22 = Invalid argument Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) cifstest6:~ # dmesg CIFS VFS: Error connecting to socket. Aborting operation CIFS VFS: cifs_mount failed w/return code = -22 eventhough I can ping the ipv6 interface on the server ping6 -I eth0 fe80::214:5eff:fefb:3f7c PING fe80::214:5eff:fefb:3f7c(fe80::214:5eff:fefb:3f7c) from fe80::214:5eff:fefb:3f54 eth0: 56 data bytes 64 bytes from fe80::214:5eff:fefb:3f7c: icmp_seq=1 ttl=64 time=3.92 ms 64 bytes from fe80::214:5eff:fefb:3f7c: icmp_seq=2 ttl=64 time=0.146 ms Do you see any error messages like this? You can clear syslog buffer dmesg -c turn on cifs debugging by doing echo 7 > /proc/fs/cifs/cifsFYI issue the mount command and obtain syslog buffer by doing command dmesg and send that output
After turning on debugging, echo 1 > /proc/fs/cifs/cifsFYI echo 1 > /proc/fs/cifs/traceSMB I see following messages in syslog buffer. The client is at 2.6.29-rc7-1-default and server is at 2.6.27.8-1-default. cifstest6:~ # dmesg fs/cifs/cifsfs.c: Devname: //cifstest8/smb8 flags: 64 fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 2 with uid: 0 fs/cifs/connect.c: Username: root fs/cifs/connect.c: UNC: \\cifstest8\smb8 ip: fe80::214:5eff:fefb:3f7c fs/cifs/connect.c: attempting ipv6 connect fs/cifs/connect.c: ipv6 Socket created fs/cifs/connect.c: Error -22 connecting to server via ipv6 CIFS VFS: Error connecting to socket. Aborting operation fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 2) rc = -22 CIFS VFS: cifs_mount failed w/return code = -22 Took a wireshark trace during this but do not see any traffic over ipv6 source and destination (interface) addresses.
When ip=<ipv6_address_of_the_samba_server> option is specified, nothing is logged on the samba server, so nothing goes out on the wire from the cifs vfs client (wireshark trace also confirms that) to the samba server. Need to figure out what and why this error fs/cifs/connect.c: Error -22 connecting to server via ipv6
Something incorrect in connect system call in function ipv6_connect() to generate EINVAL (22) error.
I think this failure (in my case) has to do something with the scope of the address (Scope:Link) inet6 addr: fe80::214:5eff:fefb:3f7c/64 Scope:Link I suspect the ipv6 address you are using has similar scope, Scope:Link when the error EINVAL is genereated, connect just does not succeed.
If your network interface can be configured with a Scope:Global or a Scope:Site address, I think mount would succeed (i.e. would not generate EINVAL -22).
Julien Cristau notes that, since the target IP in the example is a link-local address, it's necessary to specify an interface name the same as you do when calling ping. The syntax for this is: fe80::214:5eff:fefb:3f7c%eth0 However, even when specifying the interface name a mount.cifs still fails for me.
Yes, I'm not sure that we really can support link-local addresses (and tbh: I'm not exactly sure yet how we should support them). Our address parser doesn't understand interface names in the scope... I could be wrong, but aren't link-local addresses really only supposed to be used for things like neighbor discovery? Some confirmation of the problem from the original reporter might be nice. An strace of the mount command that shows a link-local ip addr in the mount options, for instance... > If I pass options -o user=user,ip=servername,noperm the same error 22 is risen. That's expected since you're passing something that isn't an IP address into the kernel as if it were. When "ip=" is explicitly specified then the mount helper doesn't bother with name resolution and passes it on directly.
I see bug 4548. This probably needs to be returned as a duplicate of 4548. Looking into 4548
Shirish is right: this is a duplicate of #4548 *** This bug has been marked as a duplicate of bug 4548 ***