"Open file manager" button not working

Buras · July 4, 2025, 6:51am

So after running journalctl -xe I've got this output:

lip 04 08:49:22 buras-ThinkPad-X201 gnome-shell[1977]: JS ERROR: TypeError: app is null
                                                       DriveMenu/<@/usr/share/gnome-shell/extensions/drive-menu@gnome-shell-extensions.gcampax.github.com/ext>
                                                       addAction/<@resource:///org/gnome/shell/ui/popupMenu.js:559:21
                                                       activate@resource:///org/gnome/shell/ui/popupMenu.js:197:14
                                                       vfunc_button_release_event@resource:///org/gnome/shell/ui/popupMenu.js:141:14

I suppose the extension doesn't know, which app to run.

Forpli · July 4, 2025, 7:22am

You could uninstall this extension "Removable drive menu" completely with gome extension manager and then install it again. Make sure you choose gnome version 43 there.

Removable Drive Menu - GNOME Shell-Erweiterungen Removable Drive Menu - GNOME Shell Extensions

Buras · July 4, 2025, 7:32am

The problem is, I don't have uninstall button in Gnome Extension Manager. I can only disable Removable Drive Menu.

Forpli · July 4, 2025, 8:09am

Then I'd open nautilus with sudo rights:
"sudo -i"
"nautilus"

Then go to

usr/share/gnome-shell/extensions

and search for

drive-menu@gnome-shell-extensions...

Copy this file somewhere into your Home folder where you can find it again, e.g. on your desktop.

Then delete the file "drive-menu@gnome-shell-extensions..."(please enter the complete name of the file here)

Reboot your system.

Then open gnome extension manager, search for the removable drive extension and install it.

Ponce-De-Leon · July 4, 2025, 9:37am

I already know that. But the Thing is: I din't know the Package Name for Installation. And because it comes as a System Extension, You don't have an Uninstall Button in Extension Manager.

I have found the other Packages Names for the Extensions but not this one.

zenzen · July 4, 2025, 10:00am

Sorry, one of the nuances of the journalctl command is that it uses a pager instead of showing the full contents...

Could you run that command again and use the right arrow to scroll horizontally on the line that starts with "DriveMenu" to show the full contents? It's not immediately obvious but it gets cut off and it's not clear where the error happens.

DriveMenu/<@/usr/share/gnome-shell/extensions/drive-menu@gnome-shell-extensions.gcampax.github.com/ext>
                                                                                     this is cutoff ^^^

For comparison, if you look at the next line from the snippet you shared, you can see that there's an number indicating the line number within that file where the error happens. In this case 559:

addAction/<@resource:///org/gnome/shell/ui/popupMenu.js:559:21
                                                        ^^^

So, whatever that number is for the previous line that we're interested in, that's where the error happens. Then, you can run the following command:

awk 'NR == 169' /usr/share/gnome-shell/extensions/drive-menu@gnome-shell-extensions.gcampax.github.com/extension.js

I'm using 169 because I suspect that's where the error is, looking a bit into the code, but make sure to replace it with whatever line number the log shows.

Now, I'm going to get ahead of myself here and assume that is the correct number and the output of the previous command looks something like this:

let app = appSystem.lookup_app('org.gnome.Nautilus.desktop');

If that is the case, what this means is that the .desktop file for the file manager cannot be found, or there's something wrong with it.

You can find that out by inspecting that the file exists with:

cat /usr/share/applications/org.gnome.Nautilus.desktop

If the file doesn't even exist, this will show an error message. If it does, it will show the contents of this file. Please copy and paste it here to see what's wrong with it.

Buras · July 4, 2025, 10:10am

Firstly, I've completely removed that extension manually and then installed the one I've downloaded. I found out that it was in different language, so I've checked the script and translated it myself. During that I've came across a reference to org.gnome.Nautilus.desktop.

The error says:

JS ERROR: TypeError: app is null
                                                       DriveMenu/<@/usr/share/gnome-shell/extensions/drive-menu@gnome-shell-extensions.gcampax.github.com/extension.js:170:13
                                                       addAction/<@resource:///org/gnome/shell/ui/popupMenu.js:559:21
                                                       activate@resource:///org/gnome/shell/ui/popupMenu.js:197:14
                                                       vfunc_button_release_event@resource:///org/gnome/shell/ui/popupMenu.js:141:14

So, if app is NULL then in fact the could be a problem with .desktop file. I've checked its contents:

[Desktop Entry]
Name=Files
Comment=Access and organize files
# Translators: Search terms to find this application. Do NOT translate or localize the semicolons! The list MUST also end with a semicolon!
Keywords=folder;manager;explore;disk;filesystem;nautilus;
Exec=nautilus --new-window %U
# Translators: Do NOT translate or transliterate this text (this is an icon file name)!
Icon=org.gnome.Nautilus
Terminal=false
Type=Application
DBusActivatable=true
StartupNotify=true
Categories=GNOME;GTK;Utility;Core;FileManager;
MimeType=inode/directory;application/x-7z-compressed;application/x-7z-compressed-tar;application/x-bzip;application/x-bzip-compressed-tar;application/x-compress;application/x-compressed-tar;application/x-cpio;application/x-gzip;application/x-lha;application/x-lzip;application/x-lzip-compressed-tar;application/x-lzma;application/x-lzma-compressed-tar;application/x-tar;application/x-tarz;application/x-xar;application/x-xz;application/x-xz-compressed-tar;application/zip;application/gzip;application/bzip2;application/vnd.rar;
X-GNOME-UsesNotifications=true
Actions=new-window;
X-Unity-IconBackgroundColor=#af4853
X-Ubuntu-Gettext-Domain=nautilus

[Desktop Action new-window]
Name=New Window
Exec=nautilus --new-window

zenzen · July 4, 2025, 10:37am

What is the output of:

awk 'NR == 170' /usr/share/gnome-shell/extensions/drive-menu@gnome-shell-extensions.gcampax.github.com/extension.js

And what is the exact name of the .desktop file?

Buras · July 4, 2025, 11:17am

Here's the output:

app.activate_full(-1, event.get_time());

Here's the file name:

org.gnome.Nautilus.desktop

Buras · July 4, 2025, 12:28pm

Update: I've changed .desktop file in the script to a temporary one and the button does in fact launch other app (I've tried with VirtualBox).

zenzen · July 4, 2025, 1:36pm

Good thinking, it seems it's just this one desktop file for some reason.

Let's try a few things (after reverting the desktop file to what it was, as per your previous post):

Run sudo update-desktop-database. This should update the cached of desktop entries. Test if this makes any difference.
Copy the desktop file to another location where it should also work:
```
sudo cp /usr/share/applications/org.gnome.Nautilus.desktop ~/.local/share/applications
sudo chown $USER:$USER ~/.local/share/applications/org.gnome.Nautilus.desktop
```
The second command here is to assign ownership, since these need to run with elevated permissions. Test if this makes any difference.
Check environment variables to see if the system is looking in the right locations (probably, but just to check):
```
env | grep -i xdg
```
We're interested in the variables XDG_DATA_HOME and XDG_DATA_DIRS.

Buras · July 5, 2025, 7:09am

That didn't work.
That DID work. So it seems that the extension has a problem with file location. I've checked the ownership after copying and it was already associated with my user account.
Here's the output:

XDG_CONFIG_DIRS=/etc/xdg/xdg-zorin-xorg:/etc/xdg
XDG_MENU_PREFIX=gnome-
XDG_SESSION_DESKTOP=zorin-xorg
XDG_SESSION_TYPE=x11
XDG_CURRENT_DESKTOP=zorin:GNOME
XDG_SESSION_CLASS=user
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/usr/share/zorin-xorg:/usr/share/gnome:/home/buras/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop

The problem has been resolved. Thank you so much for your help, everyone. I'm not sure, if I should close the topic - maybe someone would like to investigate the problem.

Oh, and one more thing: Zorin Menu and uLauncher can search for file manager now. So the problem is more system wide, I guess.

zenzen · July 6, 2025, 9:48am

I wish I could say that I know what the problem is exactly... but I'm glad that it worked!

We can leave this thread as it is since it will close automatically after some period of inactivity. I have some ideas we can try for the time being; feel free to try them at your own leisure as I'm also curious about what's going on here.

My best guess at the moment is there's either something wrong with the original .desktop file itself. Since we already checked its contents, it's possible it's it has incorrect permissions somehow, or maybe there's a faulty duplicate somewhere...

We can check for both cases:

find $(echo -n $XDG_DATA_DIRS | sed 's/:/\/applications /g') -type f -name org.gnome.Nautilus.desktop -exec stat '{}' \+ 2>/dev/null

This will search for a file named "org.gnome.Nautilus.desktop" inside every directory listed in the XDG_DATA_DIRS environment variable, and print information about it.
If there are multiple files with this exact name in different directories, that could be a hint as to what the problem is, assuming there's something wrong with one of them. Note that in your case you should see at least two results given how you've made a copy, as per my last reply. That's also fine, there's nothing wrong with having multiple files per se, and we want to check all of them anyway.

Buras · July 6, 2025, 5:04pm

Let's investigate it then

Here's the output:

  Plik: /usr/share//applications/org.gnome.Nautilus.desktop
  rozmiar: 1240      	bloków: 8          bloki I/O: 4096   plik zwykły
Urządzenie: 802h/2050d	inody: 659683      dowiązań: 1
Dostęp: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Dostęp:      2025-07-06 12:48:59.093015376 +0200
Modyfikacja: 2025-03-11 22:25:08.000000000 +0100
Zmiana:      2025-07-03 14:25:53.908768050 +0200
Utworzenie:  2025-07-03 14:25:53.885767633 +0200

zenzen · July 7, 2025, 7:32am

Ok, let's try a few things and see what sticks:

We're going to "hide" the original .desktop file, now that you have a copy made on another location that seems to work. And by "hiding" I mean renaming the file to something that shouldn't be detected as a valid .desktop file, by simply changing the extension:
```
sudo mv /usr/share/applications/org.gnome.Nautilus.desktop /usr/share/applications/org.gnome.Nautilus.desktop.bak
```
Log out, log back in, and test if everything still works.
Assuming that it everything works, we can now try to create a symbolic link (a shortcut) to the new file that you copied earlier and that we now it's working. This is just to see whether it makes any difference what type of file we're using.
```
sudo ln -s $HOME/.local/share/applications/org.gnome.Nautilus.desktop /usr/share/applications/org.gnome.Nautilus.desktop
```
Log out, log back in, and test if everything still works.
I suspect that this issue is somehow related to how different files are cached internally by the Gnome desktop environment. If at this point everything works, we can move on to the real test which is to revert things they way they were.

Be careful when running these commands, if you are going to type them manually.
- First, remove the symbolic link created in the previous step:
```
sudo rm /usr/share/applications/org.gnome.Nautilus.desktop
```
- Then, rename the .desktop file from your user directory, which solved the issue earlier, to "hide" it:
```
mv $HOME/.local/share/applications/org.gnome.Nautilus.desktop $HOME/.local/share/applications/org.gnome.Nautilus.desktop.bak
```
- Lastly, restore the original file:
```
sudo mv /usr/share/applications/org.gnome.Nautilus.desktop.bak /usr/share/applications/org.gnome.Nautilus.desktop
```
Log out, log back in, and test if everything still works.

Buras · July 7, 2025, 7:49am

After doing all these steps everything still works. Assuming that a system takes into consideration only .desktop files and not .desktop.bak files, your theory about caching could be correct.

Forpli · July 7, 2025, 8:41am

Yes, only files that end with .desktop are recognized as desktop files. When you add bak or another suffix they get hidden for the system and no longer fullfill the function as desktop files.

zenzen · July 7, 2025, 9:25am

Great, at least we have now narrowed down where the problem is. Although, I'm still not quite sure how this would happen, and why it would only affect this one file

I'll have a look at how this is handled and see what I can find. For now, you can delete local .desktop file since it shouldn't be needed anymore:

rm $HOME/.local/share/applications/org.gnome.Nautilus.desktop.bak

system · October 5, 2025, 9:26am

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.