no route to host when mounting CIFS share

Question

We have two ubuntu machines running docker + kubernetes and they need to access a windows share.

The first one is setup in /etc/fstab :

//dfs/Archive01 /mnt/dfs cifs rw,cred=/etc/cifspasswd,forceuid,forcegid 0 1

And it works, after executing mount -a we can get to the directories.

But doing the same config on machine 2 we get the dreaded "no route to host" error when trying to mount.

ping dfs

comes back with an ip-address so that works.

ip -4 addr show on the machine that's working shows:

1. ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 altname enp3s0 inet 10.203.32.80/24 brd 10.203.32.255 scope global ens160 valid_lft forever preferred_lft forever
2. docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default inet 10.200.200.20/24 scope global docker0 valid_lft forever preferred_lft forever
3. vxlan.calico: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default inet 10.244.255.192/32 scope global vxlan.calico valid_lft forever preferred_lft forever

And on the failing machine ip -4 a says:

1. ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 altname enp3s0 inet 10.203.32.81/24 brd 10.203.32.255 scope global ens160 valid_lft forever preferred_lft forever
2. docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default inet 10.200.200.21/24 brd 10.200.200.255 scope global docker0 valid_lft forever preferred_lft forever
3. vxlan.calico: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default inet 10.244.161.0/32 scope global vxlan.calico valid_lft forever preferred_lft forever

dmesg says:

CIFS: Unable to determine destination address

No clue why it's failing on the 2nd and working on the 1st. Got a feeling it has to do with the calico networks but not sure how to debug.

Anyone knows how to fix this or at least where to check?

Answer 1

Found the solution.

Forgot to install cifs-utils and keyutils on the second machine.

so just doing

sudo apt-get install keyutils 

sudo apt-get install cifs-utils

fixed it

or of course

sudo yum install keyutils cifs-utils

cloud-init (ansible?):

packages:
- cifs-utils
- keyutils

Answer 2

I had this, couldn´t connect to my Synology NAS anymore after upgrading Ubuntu 20.04 to 22.04. Apparently the upgrade had uninstalled smbclient (or else it worked without it in 20.04, not certain), cifs-utils was still installed.

Now I had to add

• keyutils (per Serve's answer, haven't tested if it is necessary)
• smbclient
• I installed winbind as well because apt suggested it, but not necessary (only for Windows domain logon). It can come in handy to connect to my laptop or the company network, but so far I'm not using it yet.

That changed it to a different error message (operation not supported) for which I had to add option vers=2.0 to the relevant lines in /etc/fstab.

-- Edit -- Checking my NAS, I found that it was set to maximum version = 2.0. Changed that and removed the 'vers=2.0' from /etc/fstab, and it works. Apparently auto-negotiating the protocol version doesn´t work too good when you set a maximum on Synology.