Resolved SSH terminal: "libtinfo.so.6: cannot open shared object file", possibly caused by Centos2Alma migration

[Bitpalast]

Server operating system version

Alma 8

Plesk version and microupdate number

18.0.71 #2

Alma 8
Obsidian 18.0.71 #2
SSH Terminal extension 1.4.1-281

Opening the SSH terminal results in a system error message: "error while loading shared librarires: libtinfo.so.6: cannot open shared object file: No such file or directory"



How can this be fixed? It's a standard Alma 8 installation.
I could not find hints in Plesk support pages on the error.

 

[Martin Dias]

What SSH access does the user have enabled?

 

[Bitpalast]

It's a subscription. It has "/bin/bash (chrooted)" as a shell.


It worked in the past, though.

 

[Bitpalast]

The same happens when the user tries to login to SSH from another system:

[11:36] >> ssh -l <sshusername> -p 22 <servername>
<sshhusername>'s password:
Last login: Mon Aug 18 10:49:46 2025 from 127.0.0.1
-: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory
Connection to <servername> closed.

So this is obviously linked to the chrooted environment, because a regular login with a server system user is possible.

 

[Martin Dias]

I cannot reproduce it on my side, I suspect that the library is missing or damaged in the template, can you check if its present and if it matches the original?

[root@10-69-45-10 ~]# ls -la /var/www/vhosts/chroot/lib64/libtinfo.so.6
-rwxr-xr-x. 2 root root 183208 Oct 29  2024 /var/www/vhosts/chroot/lib64/libtinfo.so.6
[root@10-69-45-10 ~]# sha1sum /var/www/vhosts/chroot/lib64/libtinfo.so.6
0980945413917c2f458f784005ed1e2effc72d96  /var/www/vhosts/chroot/lib64/libtinfo.so.6
[root@10-69-45-10 ~]# sha1sum /usr/lib64/libtinfo.so.6
0980945413917c2f458f784005ed1e2effc72d96  /usr/lib64/libtinfo.so.6

 

[Bitpalast]

# ls -la /var/www/vhosts/chroot/lib64/libtinfo.so.6
-rwxr-xr-x. 9 root root 187552 Oct 14  2023 /var/www/vhosts/chroot/lib64/libtinfo.so.6
# sha1sum /var/www/vhosts/chroot/lib64/libtinfo.so.6
a1dbb9a0100ab589c9996e09f6a8febe064b1687  /var/www/vhosts/chroot/lib64/libtinfo.so.6
# sha1sum /usr/lib64/libtinfo.so.6
a1dbb9a0100ab589c9996e09f6a8febe064b1687  /usr/lib64/libtinfo.so.6

It's all there.
I was able to reproduce the same issue on another Alma 8 server, too.

 

[Bitpalast]

Resolved!

I found that for some reason, Plesk did not "attach" to the bin, lib and lib64 symbolic links in the subscription's home directory. Even when the shell type was changed to "none", these links remained in the directory, so than when I re-selected "/bin/bash (chrooted)" the symbolic links could not be created anew, hence they were still pointing to a missing resource. I did not find out why this happened. It must have happened during some update, and I suspect it could have happened during the CentOS-to-Alma migration, because that was the only major change where such symbolic links might have broken and no longer linked to the correct sources on disk, as these sources were all traded against the new Alma 8 sources.

For newly created accounts this issue does not exist.

@Martin Dias Please let SandakovMM know from the GitHub - plesk/centos2alma: CentOS 7 to AlmaLinux 8 conversion tool project know, it could be worth investigating what happens to these links when his script runs.