Question marks showing in ls of directory even with root

Question

If I do ls -alt in any folder i get the following. Even with the files or folders i create with root. Commands such as stat filename returns Operation not permitted. Any idea what causes this?

[root@011319292d9c ~]# pwd
/root
[root@011319292d9c ~]# ls -alt
ls: cannot access '.': Operation not permitted
ls: cannot access '..': Operation not permitted
ls: cannot access '.bash_profile': Operation not permitted
ls: cannot access '.tcshrc': Operation not permitted
ls: cannot access '.bashrc': Operation not permitted
ls: cannot access '.bash_logout': Operation not permitted
ls: cannot access 'test-file-i-created-as-root': Operation not permitted
total 0
d????????? ? ? ? ?            ? .
d????????? ? ? ? ?            ? ..
-????????? ? ? ? ?            ? .bash_logout
-????????? ? ? ? ?            ? .bash_profile
-????????? ? ? ? ?            ? .bashrc
-????????? ? ? ? ?            ? .cshrc
-????????? ? ? ? ?            ? .tcshrc
-????????? ? ? ? ?            ? test-file-i-created-as-root

P.S. This happened inside a docker container which I started it with bash from docker image with redhat 8.5 as follows for debugging purposes:

docker run --rm -ti --entrypoint /bin/bash <Image-ID> 

Important to mention that I do not have a problem when i attached running container which is started with docker run

docker exec -ti <Image-ID> /bin/bash

Host OS of container:

cat /etc/os-release 
NAME="Red Hat Enterprise Linux" 
VERSION="8.5 (Ootpa)" 
-------------
uname -a 
Linux 3985430895d8 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Dockerfile

FROM custom-docker-image:tag

RUN microdnf update

RUN install-custom-server-modules.sh

CMD ['start-script.sh']

(!) As soon as i removed the line RUN microdnf update from Dockerfile i do not have the problem anymore.

Answer 1

I had a very similar issue on a system running SELinux. I copied some files from another directory and they showed signs like those you mentioned in your issue.

To identify the issue, i used ls -lZ on the folder (on my host) to list the SELinux labels that applied to the file (and observed that they were different from other files in the same folder).

I was able to resolve the issue by essentially re-creating the files (in my case i added them to a git stash and then restored that stash again - this caused git to recreate the files and they then got assigned the correct SELinux group for that directory)