Nautilus doesn't open in Fedora 37

Hey there!
I’m currently using Fedora 37 for testing purposes. I noticed that all apps work fine at the beginning. But after a certain time some apps, especially the file manager doesn’t open. If I try to open the file manager using the terminal using nautilus, it gives an error: Failed to register: Timeout was reached. But, if I use sudo nautilus, the file manager opens fine. What to do?

2 Likes

Please report this to the Fedora QA team, who are responsible for testing development releases (F37 currently)

https://fedoraproject.org/wiki/QA

2 Likes

Hello @fahmidbinfarooqui ,
I am one of the Fedora QA team and I would like to know more about your problem. Personally, I have not seen any such behaviour for the problem you are describing and I have been using Fedora 37 since it branched out. If anyone should be able to reproduce your situation, we need to know more info:

  • What are the application versions that you are using? The gnome-shell, nautilus, kernel are the minimum.
  • Have you upgraded to the latest versions (sudo dnf upgrade --refresh) and does your problem persist?
  • Are you using Gnome, KDE or any other desktop environment?
  • Are you using a clean installation of Fedora or have you upgraded from a previous versions (35 or 36)?
  • Are you using only the basic installation of Fedora? Only Fedora RPMs? Fedora with RPM fusion? Different applications from third parties? Flatpaks?
  • Are you using a child’s lock or a parental lock of some kind?

Thank you for the information. You can open a bug for this behaviour the Bugzilla and provide the information there, or you can provide it here and if I am able to reproduce this I could open it for you.

2 Likes

There has been a similar problem spotted on Ubuntu - gvfs - Nautilus occasionally stops working - Ask Ubuntu.

Are you using any kind of network filesystems that could go stuck and prevent Nautilus from working properly? Could the solution of that thread help you in your situation?

2 Likes

Hi @lruzicka I couldn’t find a bugzilla for this, but I am having this problem all the time, needing to kill nautilus approximately every half an hour. Here’s my information:

gnome-shell: 43.0-2.fc37
nautilus: 43.0-2.fc37
kernel: 5.19.15-301.fc37.x86_64

All upgraded to the latest versions
Using Gnome
Fresh install (official workstation)
I am using fedora RPM in all except for:

  • docker engine
  • tailscale
  • Insync
  • Proton Bridge
  • VS Codium
  • the flatpaks for Obsidian, Discord, Telegram and Signal Desktop
    No child locks.

I have several SMB mounts from a NAS, but having them mounted or not doesn’t make any difference, neither locally nor through tailscale.

This is my application landscape since Fedora 34, having started experiencing this while trying Fedora 37. I hope this helps.

I would start by creating a new user and I would try if Nautilus works fine under that new user. For me, it seems that Nautilus is working fine, which means that it might be affected by something in your system, such as a user setting, an incorrectly working network share, or something similar.
Finding the culprit will be a tedious work, but you need to do it, otherwise there will not be much to point the developers to.

1 Like

There is an important samba fix here, might help.

3 Likes

As I pointed out, the shares don’t affect the behaviour. Nautilus hangs regardless they are left mounted or not.

Another thing I noticed is that, frequently, the tracker-miner-fs service takes more than 2 minutes to shut down when rebooting the computer. May it be somehow causing nautilus to crash? How can I dig deeper in potential deadlocks between the two?

If the problem is in the user profile, and this is happening to me from a fresh install, which means my user is new, expect quite a bit if users experiencing this when they upgrade from 36 with all their dotfiles and caches.

I will wipe some caches I think they may relate to nautilus, but it doesn’t seem quite right.

Are you using an RPM or a Flatpak version of Nautilus? How does the other version behave? Can you see the same problems with the Flatpak version or vice versa?

For the non-working version, could you perhaps restart the computer and use Nautilus normally. Then when it crashes and is unable to restart, you could:

  • Collect the logs for journalctl journalctl -b > logs_from_latest_boot.txt.
  • Could you try starting Nautilus from a CLI when it does not want to start? Does it return something?

Maybe a trace of reason will be found in those logs.

The nautilis I am using is the default one, RPM.

I am working now normally with the computer with a terminal showing journalctl -f _UID=1000, so that I can check the logs next time nautilus can’t start.

Whenever nautilus won’t start, trying to launch it in the terminal shows @fahmidbinfarooqui’s output, Failed to register: Timeout was reached.

I’ll eventually try to use the flatpak one to see if/how it works, but not sure how to install it side by side and control what I am launching as I never did it.

Have you also tried the Samba upgrade that @kparal is proposing?

With Flatpak, you can use the following commands:

  1. Add the Gnome Nightly repository:
    flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo
  2. Install the latest version of Nautilus from there:
    flatpak install gnome-nightly org.gnome.NautilusDevel
  3. Then you can use a CLI command to run it:
    flatpak run org.gnome.NautilusDevel
    Using this command, you will know that you are running the Flatpak version.

Please, check if that solves the problem or not, if not, then you should definitely file a bug if not already filed. I forgot to mention that GNOME people do not track their issues in Bugzilla, for Nautilus the tracker is here: Issues · GNOME / Files · GitLab

I will try the flatpak nautilus the moment the problem reproduces again. For now, after removing a couple of caches, I am not reproducing it since a couple of hours ago.

Just checked and my version of samba doesn’t match that solution, I am assuming that is still in the fc37 testing channel (as I don’t have any pending regular updates). I will force the upgrade if it begins happening again.

Thanks all!

Yeah, the new Samba is still in testing. :slight_smile:

FYI, I think I’m seeing this same issue after doing the official update from Fedora 36 to Fedora 37.

This is a fairly fresh install (installed fedora 36 a couple weeks ago), just updated to 37 (via Gnome Software app) , and before updating I had recently set up samba mostly following directions in https://docs.fedoraproject.org/en-US/quick-docs/samba/ .

Things tried:

  • Shutting down samba server via ‘sudo systemctl stop smb’ , didn’t seem to have an effect.
  • trying ‘sudo nautilus’ in CLI, works while just doing ‘nautilus’ doesn’t
  • @kparal’s mention of samba update - was already up to date
  • @lruzicka 's mention of trying nautilus nightly build, does work.

After rebooting, things worked again. I was able to sorta reproduce it by launching Dropbox (had nautilus (regular fedora version) crash on me while window was open, couldn’t open it again). After rebooting once more, can’t seem to reproduce it yet.

I’ve just updated to F37 and can’t reproduce it.

I got the same issue after update to F37:

✗ G_MESSAGES_DEBUG=all nautilus                                                                                                                     
(org.gnome.Nautilus:56962): GLib-GIO-DEBUG: 13:43:49.434: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)
(org.gnome.Nautilus:56962): GLib-GIO-DEBUG: 13:43:49.436: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ?gio-vfs?
(org.gnome.Nautilus:56962): Tracker-DEBUG: 13:43:49.450: Loading ontologies from database.
(org.gnome.Nautilus:56962): Tracker-DEBUG: 13:43:49.453: Applying ontologies from /usr/share/nautilus/ontology to existing database
(org.gnome.Nautilus:56962): Tracker-DEBUG: 13:43:49.455: Current and DB locales match: 'C'
** (org.gnome.Nautilus:56962): DEBUG: 13:43:49.458: *** Cancel Results Meta requests
Failed to register: Timeout was reached
(org.gnome.Nautilus:56962): Tracker-DEBUG: 13:44:14.483: Cleaning up stale resource URIs

If I delete the ~/.cache/tracker3 folder, Nautilus is getting working.

But some time after, Nautilus is stopping to work. I have to delete one again this tracker folder to use it.

Experiencing same issue.

Timeout was reached

I used System monitor and killed the nautilus.
In my case I had a nautilus extension nautilus-gsconnect and nautilus-tilix. I thought maybe that’s what causing the issue and deleted everything from
~/.local/share/nautilus-python/extensions/
and reboot. For now it works without that behavior.

On reboot I have tracker-miner-fs thingy running and takes like 2 mins to stop that service.
I also have an issue with Skype. Everytime I login and exit, The next time it will just sign me out of it.
Which according to others is an issue with gnome-keyring.

Do you have any nautilus plugins installed?
Thanks

➜  ~ dnf list installed | grep nautilus 
gnome-terminal-nautilus.x86_64                       3.45.90-1.fc37                      @fedora                                        
nautilus.x86_64                                      43.0-2.fc37                         @fedora                                        
nautilus-extensions.x86_64                           43.0-2.fc37                         @fedora 

I think it’s related to Tracker. I created a bookmark on a folder containing a lot of files (a lot of PDF ebooks) and its all content is indexed by Tracker.

I have no Nautilus extensions:

➜  ~ ls -ldh ~/.local/share/nautilus*                            
~/.local/share/nautilus
➜  ~ ls -ldh ~/.local/share/nautilus/*
~/.local/share/nautilus/scripts
~/.local/share/nautilus/tags
~/.local/share/nautilus/tracker2-migration-complete