Thunar - Frequently Asked Questions
The intent of this section is to collect the quite numerous frequently asked questions that relate to working with Thunar. If you know of a question that is missing from this page, please file a request.
Why does Thunar forget its settings when run as root?
Thunar relies on xfconf to load/store its settings, The communication to xfconf is done via DBUS. When run as root, per default, no dbus-session is running.
You can start Thunar as root with dbus-session with the following command:
$ sudo dbus-run-session thunar
or
$ gksu dbus-run-session thunar
Why doesn't Thunar execute files marked as executable?
For security reasons, by default Thunar only executes files of type application/x-desktop, application/x-executable and application/x-shellscript. For desktop files the execution will only be possible if the desktop file is of type Application, the execute flag is set and the file is trusted. (desktop files inside XDG_DATA_DIR are executable by default).
Also note that for application/x-executable and application/x-shellscript, the types of the file don't really need to match these types exactly, but it is sufficient if the detected type has a parent that matches one of the two types listed above, or if the MIME-type is an alias for one of the above.
Execution of binary files explicitly needs to be enabled in the advanced preferences.
Where does Thunar store the metadata associated with files?
Thunar has its file and folder metadata storage implemented as a set of key/value pairs. Since 1.6, this data is stored using the gvfs-metadata daemon. The location of the metadata is kept in $XDG_DATA_HOME/gvfs-metadata (generally $HOME/.local/gvfs-metadata. The format the data is stored in is binary; but, it can be queried and viewed using the gio command.
For example:
The command gio info -a metadata:: /some/location will return an abbreviated list of key/value pairs including the file's URI, local path, and unix mount.
For a more detailed list of file information, omit the -a metadata:: flag. This will return details such as icon type, access permissions, time created, etc.
See GIO File Attributes page for additional types of data stored.
Where does Thunar store its preferences?
Thunar stores the user configurable preferences (and hidden settings) in an Xfconf channel. You can view the contents of this settings channel with the Settings Editor.
For an overview of the hidden settings, you can find an overview here.
How to use mouse gestures in Thunar?
Thunar currently features basic support for so called mouse gestures in its icon view. You can use these mouse gestures by holding down the middle mouse button (usually the mouse wheel) while the mouse pointer is on the background area of the icon view component (any area that is not covered by an icon or a text). Now you can move the cursor into four directions to perform certain actions, which are described below.
- Left – opens the previous visited folder
- Up – opens the parent folder
- Right – opens the next visited folder
- Down – reloads the current folder
How do I assign different keyboard shortcuts?
Starting with thunar 4.18 you can make use of the shortcuts editor to assign keyboard shortcuts.
For Thunar 4.16 and before, please refer to the previous Wiki pages.
Note that for some keys the <Shift> modifier seems to be ignored. (E.g. <Primary><Shift>1 fails, where <Primary>exclam works fine.) Most likely a gtk bug.
Check the keynames.txt for a list of available keys.
If you are a packager, or a system administrator, and want to provide a system wide default for the keyboard shortcuts, that is different from the default shortcuts in Thunar, you can create a file Thunar/accels.scm in one of the $XDG_CONFIG_DIRS. For example, if /etc/xdg is part of $XDG_CONFIG_DIRS (the default for most Linux distributions), you can install system wide defaults to /etc/xdg/Thunar/accels.scm. Thunar will then load shortcuts from this file on first startup.
Why does Thunar display the fall-back icon for all files and folders?
If Thunar displays the fallback icon for all files and folders, as shown in the screenshot below, it is usually caused by one of the following problems:
| Fallback Icon |
|---|
|
- You don't have an XSETTINGS manager running,
- or the selected icon theme does not follow the GNOME naming scheme for MIME icons or it does not contain any MIME icons at all.
The first problem can be fixed by running an XSETTINGS manager in your desktop session, for example xfce-mcs-manager or gnome-settings-daemon. Modern desktop environments automatically spawn a settings manager on startup, so you shouldn't experience this problem in Xfce or GNOME. If you don't want to run an XSETTINGS manager, you can also specify an icon theme in your ~/.gtkrc-2.0. For example to use the Tango icon theme add a line
gtk-icon-theme-name = "Tango"
to ~/.gtkrc-2.0 (just create the file if it does not exist).
The second problem can be fixed by selecting another icon theme, which contains MIME icons (for example the Rodent icon theme, or the GNOME icon theme). In Xfce, you can do this by opening the User Interface preferences from the Settings Manager, and choosing a different theme in the Icon Theme page.
Thunar will be updated to comply with the Icon Naming Specification once the spec enters an usable state and the majority of icon themes follows the spec.
Depending on your system you might need to install the default GNOME icon theme in addition to your preferred icon theme (the Debian/Ubuntu package name is gnome-icon-theme). In either case the hicolor-icon-theme must be installed.
How to disable recently used files?
If you want to prevent the store of all files opened via thunar (or other gtk based applications), you can create
~/. config/gtk-3.0/setting.ini
and write the following inside:
[Settings] gtk-recent-files-enabled=0
How to use trash functionality on BTRFS volumes?
Some users may encounter issues with trash functionality on BTRFS volumes in Gtk based file managers like Thunar, even when the x-gvfs-trash option is specified in the /etc/fstab entry. This issue results in files being permanently deleted instead of being moved to Trash when deleted.
Workaround: To enable Trash functionality on BTRFS volumes, add a specific subvolume mount option (subvol). This workaround was identified due to limitations in GVFS support for trashing on system-internal mounts, as detailed in the GLib bug report https://gitlab.gnome.org/GNOME/glib/-/issues/1885.