ls --color hangs for directories linked from network

There is a simple workaround - this avoids ls from following symlinks (at least in the context of --color):
eval `dircolors -b | sed s/or=[^:]*://`

Try add something like this to your profile.

I can confirm this on Karmic,
Linux lambda 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux
ls (GNU coreutils) 7.4

This occurs here if I mount the nfs share foo:/c/d onto /a/B, poweroff foo and then run 'ls --color' in /a. This does not happen after I run 'sudo umount -fl /a/B'.

Still reproducable on lucid.
~/ext is a symlink to /media/ext here which is a NFS mount.

strace ls --color=auto shows:
lstat64("ext", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
readlink("ext", "/media/ext", 11) = 10
stat64("/media/ext",

the same while /media/ext is available gives:
lstat64("ext", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
readlink("ext", "/media/ext", 11) = 10
stat64("/media/ext", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0

The lstat64 call is done for all files/dirs with --color=auto, while readlink() and stat64() only get called for symlinks.

Do not expect this to be fixed in coreutils. There is no generally better solution I am aware of. You have in fact two choices - either give up broken checking of broken symlink at all, or wait some time for the symlinks to be checked. Consider using timeout(1) utility to not wait indefinitely in that case.

I am tending to close this one WONTFIX...

I don't think this bug should be closed or label WONTFIX.

Nothing should hang.

I recently face similar issue and ls keeps hanging and even the workaround with eval doesn't fix it.

I reported Bug #906643 which involves sshfs and this eval work-around didn't work for me. Not sure if the cause (following symlinks for coloring) is similar in my case.

I can confirm this on Ubuntu 14.04, but as has been pointed out, I don't really expect a "fix" to this. However, the workaround at first didn't work for me until I'd figured out that you ALSO have to make sure that you don't have an alias set for ls which uses the "-F" option.

"-F" tries the same as the "or=..."-Option in dircolors - it categorizes the files in a directory listing, and therefore tries to determine whether or not a symlink is broken.

To determine whether the workaround works for you, try this:

eval `dircolors -b | sed s/or=[^:]*://`
\ls -l --colors=auto

The backslash in front of the ls-command circumvents any set aliases, so you get the real behaviour of exactly the following command.

Same issue in Ubuntu 18.04.

The workaround mentioned works for me. For fish users: Put

eval (dircolors -c | sed 's/or=[^:]*://')

in your `~/.config/fish/config.fish`.

And you have to modify the builtin `ls` function:

cp /usr/share/fish/functions/ls.fish ~/.config/fish/functions/

Then open `~/.config/fish/functions/ls.fish` and comment out this line:

set -a param --indicator-style=classify

I do think the fact that a workaround exists is not enough. I really think the default behaviour in Ubuntu of a oft-used command should not create hangs of well over a minute in fairly standard circumstances. It also hangs on links that are not accessible because they have not been Kerberos authenticated or are on unmounted USB devices.

So I do think the default should at least be changed here. It is unreasonable default behaviour, not least because it is really unobvious to most users why it happens.