Too Many Levels of Symbolic Links Fix – Linux
This error happens when a symlink chain loops or breaks. The fix is finding the broken link and fixing it. Don't waste time restarting services.
Yeah, that error is annoying. You try to ls a directory or run a script, and boom – Too many levels of symbolic links. The system's telling you it hit a loop in symlinks. Let's fix it.
The Fix – Find and Kill the Loop
The culprit here is almost always a symlink pointing back to itself or forming a circular chain. The quickest way to track it down is with find and ls.
Start from the path that gave the error. For example, if it's /opt/someapp/lib, run:
ls -la /opt/someapp/lib
Look for symlinks with crazy arrows like libfoo.so -> libfoo.so or a series of links pointing to each other in a circle. If you see one that looks wrong, check its target:
readlink /opt/someapp/lib/libfoo.so
If it points back to itself or to another symlink that loops, you found it. Fix it by pointing to the real file, or just delete the broken symlink and recreate it correctly.
Batch Check with find
If the error's vague and you don't know the exact file, scan the whole directory with find to detect loops:
find /path/to/problem -type l -exec ls -la {} \;
This lists every symlink and where it points. Look for paths that repeat. A symlink like a -> b -> c -> a is a three-link loop. Delete the whole chain and start fresh.
Why This Happens
Linux has a limit on how many symlinks it'll follow before giving up. That's 40 by default on most distros (check with getconf SYMLOOP_MAX). A loop means you hit that limit. It's not a bug in the kernel – it's a protection against infinite loops.
Common real-world trigger: you install a package manually, and one symlink gets set to itself because of a typo in a script. Or you use ln -s with the wrong source path. I've seen it happen when moving files between servers via rsync and the symlinks don't update correctly.
Less Common Variations
Sometimes it's not a loop – it's a chain that's too deep. Like a -> b -> c -> d ... going 50 levels deep. Rare, but possible if you're generating symlinks programmatically. Check with namei to trace the whole chain:
namei -l /path/to/link
It shows each step. If you see a repeating pattern or a list that's too long, you've got a chain problem. Shorten it by linking directly to the final target.
Another odd case: the symlink target exists but you don't have search permission on intermediate directories. This can trick you into thinking it's a loop. Use ls -ld on each parent directory to check permissions. Add execute (x) permission with chmod +x on directories that need it.
Prevention Tips
Don't rely on long symlink chains for anything important. One level deep is fine – it's easy to debug. If you're automating symlink creation, add a sanity check:
ln -s /real/target /link/path
if [ $(readlink /link/path) == "/link/path" ]; then
echo "Loop detected!"
rm /link/path
fi
Also, avoid creating symlinks relative to the current directory unless you're sure the path won't change. Absolute paths are safer for production scripts. And if you're migrating data, use cp -a to preserve symlinks correctly, or test with rsync --dry-run first.
Finally, run a quick periodic check with cron:
0 3 * * 0 find /important/path -type l -xtype l -delete
This deletes dangling symlinks (pointing to nothing) every Sunday at 3 AM. Won't fix loops, but reduces clutter that can confuse people.
That's it. Symlink errors are easy to kill once you know where to look. Don't overthink it – just find the loop, break it, and move on.
Was this solution helpful?