I'm wondering why Nautilus is very slow when opening a directory containing lots of files. My /usr/lib dir for example has 1900 files and it takes approximately 5+ seconds to show everything. It has been like this since I installed Ubuntu few months ago and it's really quite annoying sometimes. I don't have powerful hardware but I know that Windows Explorer is so much faster than this.

Is there anything that can be done to speed it up?

Ubuntu 10.04

  • 1
    My guess would be that Nautilus utilizes ls to make its list while Explorer has a cache.
    – digitxp
    Aug 14, 2010 at 20:53
  • What kind of system it is? I think this is a big factor. It would be "slow" on my netbook, but not so much on an i7 with with 4+GBs of ram.
    – Chris
    Aug 26, 2010 at 18:30
  • Related on Ask Ubuntu: Nautilus is very slow
    – slhck
    Jan 31, 2013 at 13:02

7 Answers 7


Tracing the execution of nautilus shows that the slowness is due to a combination of two factors:

  • It's smart about displaying useful information about each file. It looks inside the contents of files to determine what icon to use, and possibly show a preview. This can be toned down by turning previews off in the preferences.

  • It does a lot of useless work (such as stating each file multiple times, and checking /proc/filesystems even for non-directories). All you can do is learn programming, improve the program and send a patch. Or at least send the authors a feature request (please make it faster).

  • It calls several external processes for each directory, I haven't explored what they do.

  • Good answer :D! +1 for patching + featurerequestrequest :D
    – Pylsa
    Aug 14, 2010 at 21:39
  • I'm a programmer, though not yet good enough to contribute. Just out of curiosity, how did you do the trace? Aug 14, 2010 at 21:52
  • 2
    @Derek: strace -f -ttt -p1234 -o nautilus.strace where 1234 is the pid of nautilus. I haven't analyzed the trace in detail, just glanced at the lead up (lots of stuff involving subprocesses) and the per-file stuff (multiple stats, and an open for some files). Aug 14, 2010 at 21:57
  • 1
    A lot of the multiple stat()'s come from library calls, many from glibc.
    – Tim Post
    Aug 17, 2010 at 11:05
  • 2
    woah, this has been an issue since over 6 years! how come still noone has invested the time in this? To start with, previews & stats should be done AFTER listing the files. Thus, listing huge folders will be as instant as ls and browsing will be possible while the previews are being loaded. Windows Explorer works like this, if I remember correctly. Kind of unbelievable for a highly used Ubuntu program like this. however, shouldn't complain but contribute instead
    – phil294
    Nov 24, 2016 at 13:09

In the "Preview" tab under "Edit -> Preferences", try switching all the options to "Never".

It also helped me enormously to turn off "Assistive Technologies". You can do this in "System -> Preferences -> Assistive Technologies". Uncheck "Enable assistive technologies".

You'll have to log out and back in for the latter change to take effect.

  • This gives me very modest improvements. Deleting bookmarks made a much bigger difference. Jan 31, 2013 at 12:53

This reminded me of a talk I had with Alexander Larsson, the lead developer for Nautilus and other projects including GVFS.

Giles his answer, specifically the bit about Nautilus looking inside the content of files, touches on the major reason why Nautilus is "slow". However Giles doesn't explain why this is slow, which might be obvious to some, but not to others. Here's what Alex had to say:

Say you start with a blank slate, i.e. you have not accessed the filesystem at all. Now say you run stat(“/some/dir/file”). First the kernel has to find the file, which in technical terms is called the inode. It starts by looking in the filesystem superblock, which stores the inode of the root directory. Then it opens the root directory, finds “some”, opens that, finds “dir”, etc. eventually finding the inode for file.

Then you have to actually read the inode data. After first read this is also cached in RAM. So, a read only has to happen once.

Think of the HD like an old record player, once you’re in the right place with the needle you can keep reading stuff fast as it rotates. However, once you need to move to a different place, called “seeking” you’re doing something very different. You need to physically move the arm, then wait for the platter to spin until the right place is under the needle. This kind of physical motion is inherently slow so seek times for disks are pretty long.

So, when do we seek? It depends on the filesystem layout of course. Filesystems try to store files consecutively as to increase read performance, and they generally also try to store inodes for a single directory near each other but it all depends on things like when the files are written, filesystem fragmentation, etc. So, in the worst case, each stat of a file will cause a seek and then each open of the file will cause a second seek. So, thats why things take such a long time when nothing is cached.

Some filesystems are better than others, defragmentation might help. You can do some things in apps. For instance, GIO sorts the received inodes from readdir() before stating them hoping that the inode number has some sort of relation to disk order (it generally has) thus minimizing random seeks back and forth.

One important thing is to design your data storage and apps to minimize seeking. For instance, this is why Nautilus reading /usr/bin is slow, because the files in there generally have no extension we need to do magic sniffing for each. So, we need to open each file => one seek per file => slooooow. Another example is apps that store information in lots of small files, like gconf used to do, also a bad idea. Anyway, in practice I don’t think there is much you can do except try to hide the latencies.

He ended with the following note:

The real fix for this whole dilemma is to move away from rotating media. I hear the Intel SSDs are awesome. Linus swears by them.


  • 3
    Interesting :) However, if seek is the root cause of the slowness, I'm still wondering why is Windows Explorer so much faster then? Certainly not due to hardware. Aug 17, 2010 at 20:13
  • 4
    If I had to guess I would say it doesn't do magic sniffing but simply does file detection based on the extension (I can confirm this for Windows XP). Aug 18, 2010 at 5:52
  • 2
    Exactly. Explorer (for the most part) doesn't do any kind of file sniffing, it simply uses the extension. If it needs to render a preview or read an icon, well, then it has to open the file. You can see this if you open a large folder full of .exe files. A shell extension could force Explorer to open a file to do some sniffing too. For example, some archive utilities will examine .exe files to see if they're SFX archives. MS has invested a lot of effort in doing things to try to speed Explorer up, both in actual speed and apparent speed.
    – afrazier
    Feb 17, 2011 at 21:52

I finally figured out what is making nautilus so slow: bookmarks.

To fix it delete all your bookmarks, restart and then add back the ones you can't live without.

Using strace I realised that nautilus was stating lots of files for every view. Even files that were not in directory I was browsing during the trace. I think nautilus is trying to pre-cache these bookmarks.

I had one network drive as a bookmark ... this might have been the reason why nautilus was taking several seconds to load.

  • This also applies for memory cards. :(
    – Neal Fultz
    Oct 8, 2020 at 21:49

Try using an alternative file manager such as Thunar. Thunar is much faster at loading directory listings and more stable for copying files from my NTFS usb hard drive to ext4, though with large sets of files it seems to have trouble like Nautilus.

Here's a link for switch script https://help.ubuntu.com/community/DefaultFileManager

  • Great workaround ! I love the "sudo apt-get install thunar" and "exo-preferred-applications" then select Thunar in (Utilities > File Manger) solution.
    – Doud
    Sep 20, 2011 at 1:20

If you have xfce installed in a Gnome system and you're never using it, remove exo-utils

It fixed my problem, along with the problem of Chrome not opening files correctly after they download.

  • Didn't help for me. exo-utils is also required by lots of packages including the xfdesktop4 package so it's quite hard to remove: sudo dpkg -r --ignore-depends=xfce4-terminal,thunar-volman,squeeze,thunar,xfce4-panel,xfce4-verve-plugin,xfdesktop4 exo-utils Jan 31, 2013 at 11:49

In the "Preview" tab under "Edit -> Preferences", try switching all the options to "Never".

It also helped me enormously to turn off "Assistive Technologies". You can do this in "System -> Preferences -> Assistive Technologies". Uncheck "Enable assistive technologies".

You'll have to log out and back in for the latter change to take effect.

  • 1
    Time to open a large folder reduced from about 30 seconds to maybe two seconds. Good grief.
    – wsmart
    Nov 11, 2012 at 17:39
  • My post was deleted here by another user. apparently. Wanted to say thanks to Jay for his post as it made a huge difference for my Nautius slow issue. Be real, be sober.
    – wsmart
    Nov 17, 2012 at 18:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.