How to fix broken permissions in Debian

Question

On my Debian 11 system I have one folder with obviously broken permissions. As root, I can see the folder belongs to the user ansible (owner) and has correct permissions set (0644) such that the user should easily see those files.

ansible@BACKUP:~$ sudo -s
root@BACKUP:/home/ansible# cd /opt/docker/config/opensearch/
root@BACKUP:/opt/docker/config/opensearch# ls -al
total 32
drw-r--r-- 3 ansible root  4096 Jun  8 15:38 .
drwxr-xr-x 7 ansible root  4096 Jun  8 13:28 ..
drw-r--r-- 2 ansible root  4096 Jun  8 14:14 certs
-rw-r--r-- 1 ansible root 14150 Jun  8 15:38 custom-opensearch.yml
-rw-r--r-- 1 ansible root   536 Jun  8 13:28 internal_users.yml

Back to user ansible, I do not have access to the folder though:

ansible@BACKUP:~$ whoami
ansible
ansible@BACKUP:~$ cd /opt/docker/config/opensearch/
-bash: cd: /opt/docker/config/opensearch/: Permission denied

Furthermore, I get some weird output when trying to list the directory, as I can see the file names, but not much more:

ansible@BACKUP:~$ ls -al /opt/docker/config/opensearch/
ls: cannot access '/opt/docker/config/opensearch/custom-opensearch.yml': Permission denied
ls: cannot access '/opt/docker/config/opensearch/certs': Permission denied
ls: cannot access '/opt/docker/config/opensearch/.': Permission denied
ls: cannot access '/opt/docker/config/opensearch/internal_users.yml': Permission denied
ls: cannot access '/opt/docker/config/opensearch/..': Permission denied
total 0
d????????? ? ? ? ?            ? .
d????????? ? ? ? ?            ? ..
d????????? ? ? ? ?            ? certs
-????????? ? ? ? ?            ? custom-opensearch.yml
-????????? ? ? ? ?            ? internal_users.yml

OS version:

ansible@BACKUP:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

How can I fix these permissions? Tried the usual suspects (as root):

root@BACKUP:/home/ansible# chown -R ansible:root /opt/docker/config/opensearch/
root@BACKUP:/home/ansible# chmod -R 0644 /opt/docker/config/opensearch/

Those don't make a difference.

//Edit 1: ls -alZ output added

root@BACKUP:/opt/docker/config/opensearch# ls -laZ
total 36
drw-r--r-- 3 ansible root ?  4096 Jun  8 15:59 .
drwxr-xr-x 7 ansible root ?  4096 Jun  8 13:28 ..
drw-r--r-- 2 ansible root ?  4096 Jun  8 14:14 certs
-rw-r--r-- 1 root    root ?   399 Jun  8 15:59 config.yml
-rw-r--r-- 1 ansible root ? 14150 Jun  8 15:38 custom-opensearch.yml
-rw-r--r-- 1 ansible root ?   536 Jun  8 13:28 internal_users.yml

Answer 1

Here's the reason:

root@BACKUP:/opt/docker/config/opensearch# ls -al
total 32
drw-r--r-- 3 ansible root  4096 Jun  8 15:38 .  <--- 'x' permissions missing
drwxr-xr-x 7 ansible root  4096 Jun  8 13:28 ..
drw-r--r-- 2 ansible root  4096 Jun  8 14:14 certs  <--- 'x' permissions missing

The x permissions are missing from the /opt/docker/config/opensearch directory and from the certs directory.

For regular files, the x permission means execute. For directories, it means access contents. If you have r but no x permission to a directory, you can read the names of the files and sub-directories in it, but no metadata associated with them - causing the ls -l listing of such a directory to look like this:

d????????? ? ? ? ?            ? .
d????????? ? ? ? ?            ? ..
d????????? ? ? ? ?            ? certs
-????????? ? ? ? ?            ? custom-opensearch.yml
-????????? ? ? ? ?            ? internal_users.yml

Technically, the filenames are part of the directory itself so you can see them, but as you won't have access to the inodes representing the files and sub-directories, you won't be able to see the ownership/permission/timestamp/size information.

To fix:

chmod a+x /opt/docker/config/opensearch /opt/docker/config/opensearch/certs

Occasionally, it might be desirable to have a directory with x permissions but no r, so users can access files within it only if they know in advance the exact name of the file or sub-directory they need to access. But the opposite case, a directory with r permissions with no corresponding x permissions, is - as far as I know - not really useful for any normal use.