Hi, Apologies, if this problem was already discussed on the list (my searches in the archive didn't produce a hit). Situation: our smb server is a Windows Server 2012 R2 based fileserver cluster (failover cluster with "moving" cluster role IP between the two backend nodes) behind a firewall. The "cluster fileserver role" IP is different in front of the firewall (routable IP) and behind the firewall (IP in private network). However, both IPs resolve to the same FQDN (via their respective DNS-resolvers). Access to the fileserver cluster is granted by 1:1 NAT. Using smbclient from Linux or "mount -t smbfs ..." from macOS in order to access this fileserver cluster (through the firewall) works. However, mounting a share from this fs-cluster fails, when using cifs.ko on Linux. The error returned is "mount error(5): Input/output error". The underlying error logged by the kernel is "STATUS_NETWORK_NAME_DELETED". Wiresharking revealed the difference between the working (smbclient, macOS) and failing (cifs.ko) mount attempts: the initial tree connect request for the IPC$ share has an UNC of \\fqdn\IPC$ for the working implementations, while the failing cifs.ko uses an UNC of \\external-IPv4-address\IPC$ in the "Tree Connect Request". Changing line 2523 in cifs_setup_ipc (connect.c) from snprintf(unc, sizeof(unc), "\\\\%s\\IPC$", ses->serverName); to snprintf(unc, sizeof(unc), "\\\\%s\\IPC$", ses->server->hostname); allowed me to test my hypothesis ... et voilà: now mounting with cifs.ko works as well! Is there a reason, why cifs.ko is using the server's IP address in the IPC$ tree connect payload instead of the server's hostname, as other implementations do? I am sure there is. But then: how would one get beyond a firewall without establishing some sort of proxy? Any advise or guidance would be greatly appreciated. Regards, Thomas
