A path printed by readlink is not always proof that the destination exists. On GNU/Linux, plain readlink reports the value stored in a symbolic link. Its canonicalisation options answer different questions: notably, readlink -f permits the final component to be missing, while readlink -e requires every component to exist. Choose the mode that matches the evidence you need before replacing a link or changing permissions.
Separate the stored link from the resolved destination
A symbolic link stores another pathname. If that pathname is relative, its interpretation starts from the directory containing the link, not whichever directory your terminal currently uses. Moving a relative link without its surrounding directory structure can therefore change what it points to.
Start by recording the exact link pathname and the account experiencing the problem. Avoid administrator privileges initially: a successful inspection as root can hide an access problem affecting the application account. These examples assume GNU coreutils on Linux; other operating systems may provide different options.
readlink -- /path/to/link
readlink -v -e -- /path/to/linkThe first command asks what is stored in the link. The second asks for an existing canonical destination and enables diagnostic messages. Replace the placeholder with your actual link, quoting a pathname containing spaces. Neither command repairs the link or modifies its target.
Understand why the three resolution modes differ
- Plain readlink: prints the symbolic link value. A link containing a relative pathname can produce relative output. This is not an existence check.
- readlink -f: recursively follows links and canonicalises the pathname, but all components except the final one must exist.
- readlink -e: recursively resolves the pathname and requires every component to exist.
- readlink -m: canonicalises without requiring pathname components to exist. It is useful for pathname reasoning, not proof that a file is present.
The GNU readlink manual explicitly documents these differences and recommends realpath for general canonicalisation work. Keep the chosen utility and mode in your troubleshooting notes; a screenshot of an unexplained pathname leaves out the most important condition.
Reproduce the distinction in a disposable directory
This Bash example creates a private temporary directory, one existing parent directory and a link to a deliberately absent file. It does not touch application configuration. The temporary pathname is printed so you can inspect and remove the demonstration items manually afterward.
demo=$(mktemp -d)
mkdir -- "$demo/parent"
ln -s -- parent/missing.txt "$demo/link"
printf 'Demo directory: %s\n' "$demo"
readlink -- "$demo/link"
readlink -f -- "$demo/link"
if readlink -v -e -- "$demo/link"; then
printf 'Existing destination resolved\n'
else
printf 'Existing destination was not resolved\n'
fiPlain mode shows the stored relative target. GNU -f can print an absolute destination even though missing.txt does not exist, because its parent does. The -e branch instead reports that an existing destination was not resolved. Inspect both diagnostics and exit status; an empty output alone does not explain the cause.
Investigate the cause without changing the system
If existing-path resolution fails, inspect the parent directories, expected mount and deployment records. A missing mount, a changed release directory or insufficient search permission on a parent can need very different remedies. Do not treat every failure as evidence that the final file was deleted.
If resolution succeeds but an application still fails, keep existence separate from access. The resolved object might be a directory rather than a regular file, permissions may prevent reading, or the application may see a different filesystem view. Record the exact account, operation and error rather than applying broad permission changes. For that last case, see how to compare a service mount view with your terminal.
Quick checks before any repair
- Did you record the original link value before considering replacement?
- Did you use existing-path resolution rather than relying on
-for-moutput? - Are you inspecting the same account and filesystem context as the failing application?
- Is the resolved object the intended type and accessible for the required operation?
Does successful resolution guarantee the next open will work? No. Permissions, application context and changes between inspection and use still matter. Should you immediately recreate a broken link? No. Confirm the intended destination and ownership of the configuration first; an absent mount is not repaired by pointing the link somewhere else.
Educational-use notice: Test carefully in a disposable environment before using steps in production. The site owner is not responsible for misuse, damage, data loss or production issues. This workflow is inspection-first and does not authorise changing links, permissions or mounts.
