Score:1

Nautilus sometimes spins and doesn't load everything in a dir (even a small dir)

mx flag

I often find that when I browse around my local disk using nautilus, it will not display everything, and just shows a little spinner icon. This isn't just for large directories. Sometimes, even a folder with 2-3 files will cause it to behave like this (maybe show 2 files and spin permanently, instead of showing all 3).

If I just back up one directory and go back, it usually reloads immediately.

I sometimes worry it's that my disk is starting to have issues, but I've never seen any other tools (e.g. command line utilities like ls) hang on me like this.

Should I be worried about my disk, or is this just a bug in Nautilus? Perhaps there's a cache I can clear, or maybe even some indexer I can perma-kill, assuming it won't really hurt performance. I keep my display in "list" view, so it's not like it needs to read pictures to create large icons or anything.

EDIT(2021-07-17): Adding some data requested in comments:

free -h
              total        used        free      shared  buff/cache   available
Mem:           31Gi       5.1Gi        15Gi       164Mi        10Gi        25Gi
Swap:         4.0Gi          0B       4.0Gi

SMART Data output: SMART output

heynnema avatar
ru flag
Something is wrong. Log into a different user account (create one if you need to) and see if the same problem occurs. Also show me `free -h` and screenshots of the `Disks` application's **SMART Data** window. Report back. Start comments to me with @heynnema or I'll miss them.
mx flag
@heynnema thanks! Updated post with the data - have not yet created the other user, will get to it a bit later. Things look pretty ok, though not sure what Data Address Mark Errors are.
heynnema avatar
ru flag
While waiting for your results testing under a different user account, I created an initial answer for you to follow. Report back.
vanadium avatar
cn flag
Not a hardware issue. It is a bug with nautilus I also experience now and then.
heynnema avatar
ru flag
@vanadium If you have similar Nautilus problems, then your machine needs some kind of software repair also. If you like, start a new question with the details, and I'll try to help.
vanadium avatar
cn flag
Thank you! I don't think this is likely, though. You would need to work on two different Del XPS machines. Of course, they both could be broken ;-) Nevertheless, I will follow up carefully here.
vanadium avatar
cn flag
@heynnema I just learned that my file system was last checked on 20 oktober! It thus appears that nowadays, a system file system is not anymore automatically checked! So I am increasingly believing you are hitting the nail here!
heynnema avatar
ru flag
@vanadium Check your /etc/fstab and make sure boot disk checks are enabled. Start a new question if you wish.
heynnema avatar
ru flag
@user2671688 Status please...
vanadium avatar
cn flag
@heynnema They are by default. Still, by default, a deep check is never done anymore because max mount count and max mount duration are both disabled. I find this default configuration a bit worrying.
heynnema avatar
ru flag
@vanadium Where are you seeing these values? And what is meant by *"my file system was last checked on 20 oktober"*?
vanadium avatar
cn flag
`sudo tune2fs -l <your partition>` indicates "Last checked:" date, and I tested and confirm that that is the last date of a *full* check (not just a quick check that the journal is clean: that action is not recorded).
heynnema avatar
ru flag
@vanadium To continue this discussion, we should start a new question :-)
heynnema avatar
ru flag
@vanadium Please see Update #1 in my answer. It may help you with your similar problem :-)
vanadium avatar
cn flag
@heynnema I suspect this bug https://gitlab.gnome.org/GNOME/nautilus/-/issues/1887, which has just recently been filed over at Gnome for Files 40. The bug report indicates when it happens and includes steps to reproduce it, which I can perfectly. Despite it is for 40, I strongly suspect that that is the bug that I experience for years already. Glad I can pinpoint it better now.
vanadium avatar
cn flag
@user2671688 Edit on previous comment: I cannot reproduce this on a (quite fresh) installation of 20.04. Please try the steps to reproduce the issue as indicated in https://gitlab.gnome.org/GNOME/nautilus/-/issues/1887 on your system. Similar issue also raised here: https://askubuntu.com/questions/1359166/ubuntu-20-04-2-file-manager-doesnt-show-some-files
heynnema avatar
ru flag
@vanadium Please review Update #1 in my answer. I had OP log into a different user account, and the problem couldn't be recreated... meaning the problem is specific to their normal login directory. I had outlined a number of possible suspect folders. Also, you can't recreate the problem on a fresh 20.04. But we haven't heard from OP since Aug 3, so I don't know if they tried any of Update #1.
vanadium avatar
cn flag
@heynnema I am investigating right now, and indeed, it is related to having a big thumbnail cache. Wiping the cache causes the issue to disappear. I am about to put the cache back to see whether the problem reappears.
Score:1
ru flag

We've proven that logging into a different user account solves the problem. This isolates the problem to something in your normal user account.

Let's first check your file system...

  • boot to a Ubuntu Live DVD/USB in “Try Ubuntu” mode
  • open a terminal window by pressing Ctrl+Alt+T
  • type sudo fdisk -l
  • identify the /dev/sdXX device name for your "Linux Filesystem"
  • type sudo fsck -f /dev/sdXX, replacing sdXX with the number you found earlier
  • repeat the fsck command if there were errors
  • type reboot

Update #1:

Let's try and find out what's in your normal user directory that is causing the problem.

Step #1:

Next, let's try the quickest things first... in terminal...

  • cd ~/.config # change to the .config hidden folder

  • mv nautilus nautilus.HOLD # rename a folder

  • Log out

  • Log in

  • Retry Nautilus

  • If that doesn't fix the problem, you can always rename the folder back.

Step #2:

  • cd ~/.cache # change to the .cache hidden folder

  • mv thumbnails thumbnails.HOLD # rename a folder

  • Log out

  • Log in

  • Retry Nautilus

  • If that doesn't fix the problem, you can always rename the folder back.

Step #3:

If the first two quick fixes didn't help, we'll have to try something slightly more difficult.

There are three critical folders in your /home directory that can cause problems... .cache, .config, and .local.

We'll start with .cache...

  • rename the .cache folder to .cache.HOLD
  • IMMEDIATELY log out
  • log in
  • a new .cache folder got recreated at log in time
  • see if the problem is resolved
  • if it is resolved, then something in the .cache.HOLD folder was causing the problem
    • move items from .cache.HOLD folder back into the new .cache folder...
    • BUT DO NOT REPLACE EXISTING ITEMS in the new .cache folder.
  • if it is not resolved, then the .cache.HOLD folder is not the culprit, and we need to put it back
    • to restore the original .cache folder...
    • rename .cache to .cache.NEW
    • rename .cache.HOLD to .cache
    • IMMEDIATELY log out
    • log in
    • move/delete the .cache.NEW folder
    • consult with me for the next steps... (.local, then .config)
mx flag
Thanks, will do this after getting a backup tomorrow morning. I assume, since I have all SSD, that I should only do the first step (fsck), and ignore anything under the "bad block" heading.
heynnema avatar
ru flag
@user2671688 Correct. We don't bad block a SSD. I've removed that from my answer. Is your SSD really 5 years old? Have you tested under another user account yet?
mx flag
Haha yes, my SSD is really that old. I got this system in 2014 sometime, and it's suited my needs nicely. I've been having trouble reproing even on the current user. I *think* it might only happen for media files (the place I see it most consistently is with directories where I generate/update png files). If I just `cat /dev/urandom > <filename>`, in some dir, I cannot repro.
heynnema avatar
ru flag
@user2671688 Status please...
mx flag
life got in the way for a while, plus my external hard drive died, so need to get a new one to back up before doing this.
mx flag
sorry to keep you waiting, finally got around to this. fsck didn't complain about anything. The first time I ran it, there were 5-6 "extent tree could be narrower", where I accepted the default option, and then it failed with "file system was modified", and then I reran, and it just output the 5 passes (rather quickly), and printed that it's 2.0% non-contiguous and the number of blocks.
heynnema avatar
ru flag
@user2671688 The "extent tree" messages were errors, but the "file system was modified" is normal after fixing the previous errors. The non-contiguous message is ok too. Reboot, and see if the Nautilus problem returns.
mx flag
It's still happening. This isn't happening with all folders, just ones where updates happen behind the scenes. For this specific case: I'm running a deepfake on the cloud, and I periodically download a training preview image using gsutil, which overwrites an existing png file with a new one. Then, when I go into that directory using nautilus, there's a chance it will flake out and I need to back out and re-enter. Due to the manner in which this repros, I'm more and more convinced that this a Nautilus bug, and not a filesystem issue.
heynnema avatar
ru flag
@user2671688 Look for files with strange names, or that start with a . to make it hidden. You'll have to enable "Show Hidden Files" in Nautilus to see them. Are there a lot of files in these folders? If so, you may have to tweak a parameter for Nautilus to be able to handle the quantity.
heynnema avatar
ru flag
@user2671688 Did you ever check if the problem occurs when logged into a different user account? I requested that on July 17.
mx flag
There are no hidden files in those folders. The specific example I've been playing with currently has two files. Reproing with a different user would require duplicating quite a bit of setup. Can you provide both answers you'd give (one if I can reproduce with the other user, and one if I can't)? I've already tried clearing my ~/.cache/thumbnails, since I saw that recommended elsewhere. Is there any other local stuff that would look different/cleaner under a fresh user?
heynnema avatar
ru flag
@user2671688 You don't need to create the exact circumstances that causes the problem. Just log into or create a new user, and try Nautilus on different folders, and see if you get the same problem. Report back.
mx flag
Ok. I tried and I was not able to reproduce it.
heynnema avatar
ru flag
@user2671688 Give me a minute to update my answer...
heynnema avatar
ru flag
@user2671688 Status please...
heynnema avatar
ru flag
@user2671688 Status please...
vanadium avatar
cn flag
@heynnema Step #2 applies for me. Even more chirurgically: .cache/thumbnails is the culprit if it gets too large. There are 55221 files in my thumbnails/normal, and if only that folder is cleared, all is good.
vanadium avatar
cn flag
It is not fixed, it is a workaround. You could also edit your answer to focus more on the specific cause - Step 1 should be deleted, in Step 2, only .cache/thumbnails needs deletion. Will upvote nevertheless ;)
heynnema avatar
ru flag
@vanadium In your case, it is **fixed**. Having a .thumbnails folder(s) with 55221 thumbnails is an **abnormal** situation, and could only have gotten that large after years of system use. No wonder Nautilus was having problems. For other users the bad file/folder might be different. Deleting that folder is no more a workaround than tuning /swapfile size or tweaking vm.swappiness for a system-specific configuration. Anyway, I've updated my answer as per (some of) your suggestions :-)
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.