Firstly, let me say that I am using the packaged version of Samba from Fedora 11. Here's the version info: smbclient -V Version 3.3.2-0.33.fc11 mount.cifs -V mount.cifs version: 1.12-3.3.2-0.33.fc11 It appears that at some point during the mounting process the "port" option is being ignored. It seems that no matter what is passed, mount.cifs will try port 445 but not the port specified. smbclient does not suffer from this bug. Discoverd it via port forwarding w/ SSH. To reproduce, try this: ssh -fNL 1111:localhost:445 you@your_samba_server Where, obviously, 'you' is your account name and 'your_samba_server' is a server running Samba on the standard port 445. Now, we'll try to connect: mount.cifs //your_samba_server/your_share /your/mount/dir -o ip=127.0.0.1,port=1111 mount error(111): Connection refused Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) tcpdump will verify that, indeed, mount.cifs is trying to send traffic to port 445 on the lo interface and NOT port 1111. In fact, if you kill the previous SSH session (forwarding from local port 1111 to remote port 445) and then start a new one forwarding 445 via: ssh -fNL 445:localhost:445 you@your_samba_server and mount using the SAME command (with -o port=1111) the connection is successful! It seems that this option is simply ignored. Again, let me say that smbclient does NOT suffer from this bug.
I can confirm this bug. Just upgraded to Fedora 11 and suddenly all of my SMB mounts felt away, because I've configured the samba server to use port 999 instead of the standard one (my provider closed ports 139 and 445 on all routers because of windows viruses).
As a temporary solution, you can add these rules to the *nat section in iptables: -A OUTPUT -p tcp -m tcp -d <ip> --dport 445 -j DNAT --to-destination :999 -A OUTPUT -p tcp -m tcp -d <ip> --dport 139 -j DNAT --to-destination :999 This even fixes the rusty-old bug with smbclient -L <ip> -p 999 partially working (e.g. initially it works but suddenly switches to port 139 and drops out with a timeout).
AFAIK, this is a kernel bug that has been fixed upstream. The patch should be in 2.6.31 (not sure if it got pushed to -stable series kernels). F11 should get the backported fix in kernel-2.6.29.6-213.fc11. I'll go ahead and call this one fixed, please reopen if it isn't.