GNOME – How Did GNOME Avoid Mounting My Windows Recovery USB Drive?

gnomeudisks

Sequence:

  1. Create Windows 10 Recovery Drive (USB drive).
  2. Eject drive from Windows.
  3. Now use a Linux, with the USB drive plugged in.

(The next step would be to open GNOME Disks, ensure the filesystem is not mounted, and save the recovery image. Then I can re-use the USB drive).

Result:

  • Oops, I meant to log in to Linux with my administrator account. The admin account was supposed to be the only one with access to system files like these.
  • However GNOME didn't mount the Recovery Drive, or advertise it in the file manager.

This is an 8GB USB stick, and Windows has formatted it as FAT. Windows happily mounts it. (In fact when you create it, Windows leaves it mounted; the user is responsible for unmounting it ("Eject")).

Previously GNOME has quite happily mounted Linux boot media. I actually suspect that this mounting causes Fedora Live media to fail the default boot option, which checks that the media matches the original checksum.

Does GNOME deliberately avoid mounting Windows Recovery media?

What specific aspect of this USB stick causes GNOME to treat it specially?? Is it just checking the filesystem label, "RECOVERY"??

On second thoughts, I imagine GNOME might try to avoid mounting Windows recovery partitions on your hard drive. Is this USB drive falling under the same check?

Best Answer

On my Fedora 28 system, it is hidden by /lib/udev/rules.d/80-udisks2.rules. The specific rule is:

# recovery partitions
ENV{ID_FS_TYPE}=="ntfs|vfat", \
  ENV{ID_FS_LABEL}=="Recovery|RECOVERY|Lenovo_Recovery|HP_RECOVERY|Recovery_Partition|DellUtility|DellRestore|IBM_SERVICE|SERVICEV001|SERVICEV002|SYSTEM_RESERVED|System_Reserved|WINRE_DRV|DIAGS|IntelRST", \
  ENV{UDISKS_IGNORE}="1"

So it needs two things to match: the filesystem type, and the filesystem label.

I imagine this could cause some surprise. Imagine if you happened to set the filesystem label to "Recovery" on your USB stick or SDHC card, which likely uses vfat :-).

Related Question