Shared folders not accessible after yum update

Four years later I got same problem after an update and the command “signal-event nethserver-samba-update” solved it.
I try to remove sssd-libwbclient but it was not installed.
Weird… Davidep said it was solved by released in nethserver-samba-4.3.2-1.ns7.noarch.rpm

and today it went back to non-working status… argh…

[root@mercurio ~]# alternatives --list|grep libwbclient
libwbclient.so.0.15-64 auto /usr/lib64/samba/wbclient/libwbclient.so.0.15
libwbclient.so.0.14-64 auto /usr/lib64/samba/wbclient/libwbclient.so.0.14
[root@mercurio ~]# ls -la /usr/lib64/samba/wbclient/libwbclient.so.0.14
ls: cannot access /usr/lib64/samba/wbclient/libwbclient.so.0.14: No such file or directory
[root@mercurio ~]#

There are no libwbclien.so.0.14 but alternatives show someone trying to use it ?
I’m too newbie to undestand “alternatives” usage but I do not have a .14 version shown… maybe this is the problem.

LAST UPDATE LAST WEEKED must have triggered the problem:
Installed:
kernel.x86_64 0:3.10.0-1160.105.1.el7

Updated:
curl.x86_64 0:7.29.0-59.el7_9.2 iwl100-firmware.noarch 0:39.31.5.1-81.el7_9 iwl1000-firmware.noarch 1:39.31.5.1-81.el7_9
iwl105-firmware.noarch 0:18.168.6.1-81.el7_9 iwl135-firmware.noarch 0:18.168.6.1-81.el7_9 iwl2000-firmware.noarch 0:18.168.6.1-81.el7_9
iwl2030-firmware.noarch 0:18.168.6.1-81.el7_9 iwl3160-firmware.noarch 0:25.30.13.0-81.el7_9 945-firmware.noarch 0:15.32.2.9-81.el7_9
iwl4965-firmware.noarch 0:228.61.2.24-81.el7_9 iwl5000-firmware.noarch 0:8.83.5.1_1-81.el7_9 iwl5150-firmware.noarch 0:8.24.2.2-81.el7_9
iwl6000-firmware.noarch 0:9.221.4.1-81.el7_9 iwl6000g2a-firmware.noarch 0:18.168.6.1-81.el7_9 iwl6000g2b-firmware.noarch 0:18.168.6.1-81.el7_9
iwl6050-firmware.noarch 0:41.28.5.1-81.el7_9 iwl7260-firmware.noarch 0:25.30.13.0-81.el7_9 kernel-tools.x86_64 0:3.10.0-1160.105.1.el7
kernel-tools-libs.x86_64 0:3.10.0-1160.105.1.el7 libcurl.x86_64 0:7.29.0-59.el7_9.2 libgudev1.x86_64 0:219-78.el7_9.9
linux-firmware.noarch 0:20200421-81.git78c0348.el7_9 microcode_ctl.x86_64 2:2.1-73.20.el7_9 netdata.x86_64 0:1.44.1-1.el7
netdata-conf.noarch 0:1.44.1-1.el7 netdata-data.noarch 0:1.44.1-1.el7 nethserver-base.noarch 0:3.9.1-1.ns7
nodejs.x86_64 1:16.20.2-1.el7 nodejs-libs.x86_64 1:16.20.2-1.el7 npm.x86_64 1:8.19.4-1.16.20.2.1.el7
openssl11.x86_64 1:1.1.1k-6.el7 openssl11-libs.x86_64 1:1.1.1k-6.el7 python-perf.x86_64 0:3.10.0-1160.105.1.el7
systemd.x86_64 0:219-78.el7_9.9 systemd-libs.x86_64 0:219-78.el7_9.9 systemd-python.x86_64 0:219-78.el7_9.9
systemd-sysv.x86_64 0:219-78.el7_9.9 zabbix-agent2.x86_64 0:6.4.10-release1.el7 zabbix-get.x86_64 0:6.4.10-release1.el7
zabbix-sender.x86_64 0:6.4.10-release1.el7

maybe same symptom but different cause

I was able to put 2 clients to work using hostname not IP address of NS7 server.
Not sure why, but 2 are working now… more are configurated by hand as we speak