Every time I use Nautilus and navigate to a specific subdirectory inside my home directory, Nautilus instantly closes, and the desktop wallpaper disappears too. The computer appears to continue just fine apart from this glitch, but I am never able to open that subdirectory.

I can use a terminal and ls -al in the subdirectory and I don't see anything obviously wrong to a newbie's eye. There are around 30 files in there, total maybe 200kB, mostly plaintext log files plus a few php files.

I've also just rebooted into recovery mode and ran the fsck option, just to make sure there's nothing corrupt going on, but it didn't resolve the problem.

I still think that there's some kind of file corruption going on, but I have run out of ideas.

This is a fully updated version of plain Ubuntu 13.10 without any memorable hacks or customizations (apart from moving /home to a 1TB drive while Ubuntu runs off of an SSD). The physical computer is almost new and has lots of memory; I don't think it's in any way hardware-related.

How can I troubleshoot a faulty subdirectory?

  • If it contains large amounts of small files, it may be trying to use the tracker* thing on them, to index them or something, which generally causes it to crash. I ended up setting up a keyboard shortcut to kill the tracker thing when Nautilus freezes - it runs tracker-control -k. – Wilf Dec 23 '13 at 22:05
  • I added some details. No big files, and just a few files in total. Nothing special... – Torben Gundtofte-Bruun Dec 23 '13 at 22:59
  • You might want to remove some (or all) of Nautilus extensions, as those can cause problems as well. Don't know otherwise - :-s - Nautilus just seems to crash for no reason at all... – Wilf Dec 23 '13 at 23:27
  • Does the directory have a name containing non-ASCII character sequences? – Stephen M. Webb Dec 24 '13 at 15:29
  • @StephenM.Webb no it's all plain ASCII... – Torben Gundtofte-Bruun Dec 24 '13 at 15:35

falconer's answer got me on the right track -- there was a favicon.gif in the directory that caused the error. That file must somehow be corrupt. I deleted that file and then Nautilus stopped crashing. I navigated to another subdirectory that still contains an exact copy of that file, and it crashes.

I'll see how I can report this crash as a bug. Even a malformed image file should not make the file browser crash...

  • Did you ever report this? I'm encountering the same with one SVG file. I can use mv from the terminal to move it to another folder and that folder crashes too. Definitely a file corruption. – Amanda Nov 19 '15 at 5:49

I think the problem is with the cached thumbnails which Nautilus tries to load when you open that library. On 13.10 the thumbnails are stored in ~/.cache/thumbnails try emptying that directory and see if it helps.

If it still doesn't help maybe on of the thumbnailer plugins of nautilus is broken, which deals with a specific filetype in that folder. In this case look in that directory and check if there is a filetype which is not in other directories.

Or a file in that directory is corrupted and when you open that directory Nautilus tries to cache it, but it fails because of the corruption. In this case you should check those files whether they are working and not corrupted.

  • I removed the thumbnails using cd ~/.cache/thumbnails and then rm -rf * and then pointed Nautilus to the path, but it still crashed. I'll try to move the files somewhere else using terminal and then pointing Nautilus there. That should prove whether the files are the problem. – Torben Gundtofte-Bruun Dec 24 '13 at 7:45
  • After moving the files elsewhere, they can be viewed. It's not the files themselves... – Torben Gundtofte-Bruun Dec 24 '13 at 8:26
  • @TorbenGundtofte-Bruun After moving the files can you enter the directory where they used to be? – Seth Dec 24 '13 at 22:23

There's an open bug about this problem in launchpad:


Basically, a 0 length file or a corrupted file sitting in a folder are enough to make nautilus crash when it tries to build their thumbnail.

The fastest solution seems to be to open a terminal and rm path/to/zero-length-file (if you're lucky) or identify and rm path/to/corrupted-file (if you're unlucky).

Someone reported to have solved the problem by upgrading libgtk-3-0_3.8.6 to 3-0_3.8.7, but when I'm writing that version of libgtk has not been officially released for 13.10.

Your Answer

