Search Permission on Every Directory Before the Key

Mode 0600 and the right owner do not guarantee that the service can open a key. The missing permission is usually on a directory above it. Linux resolves a path one component at a time, and each step needs search permission before the next is attempted. Read the whole path, not the last line of the listing.

Read Permission Is the Last Step, Not the Only One

Opening a file requires the kernel to walk from the root or the working directory through every component of the path. A directory without search permission stops that walk with a permission error. The file's own mode is never consulted, so a perfectly readable key looks unreadable. The error often arrives at open time without naming the directory, which is why the final file gets blamed.

For a directory, the execute bit means search, not execute-the-contents. A key stays data, and no part of this repair requires marking it executable.

Walk the Path as the Service Account

List each component with its owner and mode, then repeat the read as the actual service identity. The difference between your shell and the daemon is often the whole answer. Follow symbolic links to the real target, because the resolved path is what gets checked.

namei -l /etc/openvpn/client/office.key
sudo -u vpn-reader stat -c '%A %U:%G %n' /etc/openvpn/client/office.key

A service can also open files in more than one phase. Some material is read during privileged setup, while other files are opened after privileges are dropped. A root shell reading the file does not reproduce the later worker's access. A mount namespace can present a different view of the same path, especially inside a container, so compare the daemon's filesystem view with yours.

Change the Narrowest Permission That Fits

Choose the smallest arrangement that gives the process access: a controlled group with search on the needed directories, a managed location the service already owns, or another documented mechanism. Reading a file does not require write permission on its directory. Broad group-write permission on privileged configuration is not a normal traversal repair. Recursive 0777 is not a fix either.

Record which component you changed and why. A permission change without a recorded reason is hard to review and easy to leave behind.

Look Past Modes Only After the Walk

If the mode bits look sufficient, the remaining checks are ACLs, security policy and sandbox restrictions. An ACL can grant access that the mode bits suggest is absent, or deny access they appear to allow. Those settings belong to the existing configuration owner, and they should be adjusted narrowly rather than switched off. A root or working-directory difference can also explain an absolute path that works in one context and fails in another.

Do not lose track of what the file is while fixing access. A CA certificate is public by design; a private key is not. Files the client rewrites also need different write rights from an identity key that is read-only. Inspect metadata without printing secrets, then confirm the service itself works after the change. A short note in the service documentation saves the next person the same walk.