nautilus trash doesn't include btrfs and zfs subvolumes

Bug #1442649 reported by Karl-Philipp Richter on 2015-04-10
This bug affects 41 people
Affects Status Importance Assigned to Milestone
glib2.0 (Ubuntu)
gvfs (Ubuntu)
nautilus (Ubuntu)

Bug Description

Files in `/path/to/subvolume/.Trash-1000` aren't listed in the global trash.

Comment by bug triage team: comment 4 has a spot-on analysis of where this issue is coming from, an inconsistency between trash handling in gvfs and glib/gio. The problem has been around for quite a while.

Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in nautilus (Ubuntu):
importance: Undecided → Low
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nautilus (Ubuntu):
status: New → Confirmed

The trouble seems to stem from glib's way of deleting files being different to the way gvfs tries to locate trash directories.

glib's gio/glocalfile.c contains the find_mountpoint_for function which is used to determine the device's root directory as location to put the .Trash-<uid> directory. It looks at the stat(2) st_dev value ("device number"). btrfs gives each subvolume a different device number.

gvfs's trashlib searches for trash directories based on mount points determined by getmntent_r(2).

I do not know how to fix it in general. A fix for btrfs might be to search for all subvolumes of a btrfs mount point returned by getmntent_r(2). Not sure if you can listen to new subvolumes being created after the initial search, though (maybe inotify can?).

Rolf Leggewie (r0lf) wrote :

I can confirm the problem for btrfs subvolumes.

This problem is not limited to btrfs subvolumes. The same bug also affects at least ZFS mount points: bug 1390828, samba network mounts: bug 457047, --bind mounted directories: bug 594674, NFS mounts same bug comment 13 and tmpfs mounts same bug comment 8.

Increasing importance from low to medium as the root problem ends up affecting a much wider set of installations than initially thought.

Changed in nautilus (Ubuntu):
importance: Low → Medium
description: updated
Rolf Leggewie (r0lf) on 2016-08-21
tags: added: karmic trusty utopic
removed: third-party-packages
Changed in nautilus (Ubuntu):
status: Confirmed → Triaged
Changed in gvfs (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Rolf Leggewie (r0lf) on 2016-08-21
Changed in glib2.0 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Changed in glib:
importance: Unknown → Medium
status: Unknown → Confirmed
Jan Claeys (janc) on 2016-09-25
summary: - nautilus trash doesn't include btrfs subvolumes
+ nautilus trash doesn't include btrfs and zfs subvolumes
Ken Mollerup (kenmollerup) wrote :

The problem manifest itself on ext4 formated volumes, and Thunar!

Changed in glib:
status: Confirmed → Incomplete
Stuart Bishop (stub) wrote :

Work around is to use the trash-cli package and empty trash from the command line.

Upstream fixes in nautilus seems stalled, per , with no comments from maintainers for the several months that patches have been available.

Changed in glib:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.