Hello,
On 2019-10-21 16:23, J. R. Okajima wrote:
At least with libuchardet (probably its the same with other libraries)
the problem is not in finding the correct library. The file tried to
be
opened in line 1464, /usr/lib/x86_64-linux-gnu/libuchardet.so.0, is a
valid symbolic link to a valid normal file. But in line 1470, trying
to
open the library ends in "Permission denied". So the question is why
openat() results in EACCES here, though the link has permissions 777
and
its destination 644.
Ok, you have confirmed the permission bits of the symlink and its real
file. Then how about their attributes or ACLs, including their all
ancestors (parent dir)?
Those entries on your RO branch /live/image may look all fine. But if
your upper RW branch /live/cow contains any same named entry and its
permission bits/attributes/ACLs prohibit you searching and loading the
library, then the command will not start I am afraid.
Technically speaking, even after 1470 EACCES, the searching journey
continues, not ends. The story doesn't change though.
getfacl shows that all elements in the full path have only the normal
filesystem permissions. lsattr returns errors "Inappropriate ioctl for
device While reading flags on ...", but I also get these errors with
Debian 9, Debian kernel 4.9.110-1, aufs kernel module version
4.9+20161219-1, but there, man works normally.
There is no /usr residing in /live/cow.
Regards
Christoph
