GNOME Bugzilla – Bug 658457
List my encrypted /home partition as an object
Last modified: 2018-04-13 18:14:41 UTC
My /home is an encrypted partition, and as such, it appears as a removable device. This means I always get the removable devices notification icon in gnome-shell, even though I don't have anything else. I don't think it's right for gvfs to display this partition as a removable device anyway. I mean, it's my /home partition :-)
Cosimo might be able to comment if it's actually something that should be done at the gnome-shell level (ie, hide the mount there).
Probably caused by bug 656228 (forgot to put the bugzilla reference in commit cbc96e8fffa0d63fa). Previously we showed a volume having no mount associated, leading to inappropriate errors. I wonder if it was your case before the change or you had no icon at all. Is your /home mount in fstab?
(In reply to comment #2) > Previously we showed a volume having no mount associated, leading to > inappropriate errors. I wonder if it was your case before the change or you had > no icon at all. Is your /home mount in fstab? Hrm, I think the notification icon in gnome-shell was not showing my encrypted /home before, indeed. And yes, my /home mount is in fstab.
same happens here with an encrypted /home this bug has another interesting side-effect: Tracker will try to recursively index /home because it thinks that the partition is on a removable drive, thus will undo all the safeties in place to avoid excessive I/O and CPU usage.
*** Bug 659671 has been marked as a duplicate of this bug. ***
FYI, it turns out that only the mount object has been exposed by the referenced patch, we still used to show a volume and a drive for the /home mount. The drive is NOT marked as removable, only the volume has the can_mount flag set and the mount has can_unmount=1 (and this is actually true if you're root). This is probably the thing that made tools like tracker confused. I'm thinking about filtering out whole object trees where the end presentables are already unlocked and mounted in paths that should be ignored.
Created attachment 197768 [details] [review] proposed patch A rather risky patch where we change the way we present LUKS volumes a bit. Instead presenting the cryptotext ones (parent) we present cleartext volumes (nested) filtered through more tests. Overall it seems to be working fine, I'd appreciate futher testing on different systems. Both nautilus and gnome-shell are showing GVolumeMonitor volumes withouth further filtering, we need to do that on gvfs side.
I can only say this makes things look the right way for me :-)
(In reply to comment #6) > FYI, it turns out that only the mount object has been exposed by the referenced > patch, we still used to show a volume and a drive for the /home mount. The > drive is NOT marked as removable, only the volume has the can_mount flag set > and the mount has can_unmount=1 (and this is actually true if you're root). > This is probably the thing that made tools like tracker confused. Indeed. Tracker is making assumptions that it shouldn't be making. Therefore, adjusting bug summary to use the word 'object' instead of 'removable device'. Btw, in the future, please attach the output of 'gvfs-mount -li' and relevant entries from /etc/fstab as it makes it easier to figure out what you think the problem is. Also, bug 660595 is related to this.
Should this be applied it is not in http://git.gnome.org/browse/gvfs/tree/monitor/gdu/ggduvolumemonitor.c yet
Gdu volume monitor has been superseded by udisks2 volume monitor long time ago. I am closing this bug because many have been changed since this was reported. If this is still an issue with the recent gvfs releases, please reopen and change component to udisks2 volume monitor.