GNOME Files External Drive Trash Security Explained

When you delete a file on a removable or external drive in GNOME Files (Nautilus), the application avoids moving the file to your primary local disk to save transfer time and drive space. Instead, it processes the deletion by following the FreeDesktop.org Trash Specification, which enforces strict directory permissions and structure requirements to ensure that multiple users on the same system cannot access, alter, or exploit deleted files on shared external storage.

Adherence to the FreeDesktop.org Trash Specification

GNOME Files manages deletions across different storage volumes using the standardized FreeDesktop.org (XDG) Trash Specification. Moving files across different filesystems requires a resource-heavy copy-and-delete operation. To prevent this, GNOME Files moves the file to a designated trash directory located on the root of the external volume itself, dividing the action into two directories: files (holding the actual deleted content) and info (containing metadata such as the original path and deletion timestamp).

The Root Trash Directory (.Trash) Security Rules

If a shared top-level .Trash directory exists at the root of the external drive, GNOME Files must verify several strict security conditions before writing to it:

  1. Sticky Bit Requirement: The directory must have the sticky bit set (mode 1777), matching the behavior of system temporary directories like /tmp. This ensures that while any user can create files inside the directory, users cannot delete or rename items belonging to others.
  2. Symlink Prohibition: The directory cannot be a symbolic link. This check prevents symlink redirection attacks that could lead to unauthorized file overwrites on the host system.
  3. User-Isolated Subdirectories: Inside .Trash, GNOME Files only reads from and writes to a subdirectory named after the current user’s numerical user ID (e.g., .Trash/1000).

If the .Trash directory fails to meet any of these criteria, GNOME Files will refuse to use it.

Fallback to User-Specific Trash (.Trash-$UID)

If the root .Trash directory does not exist or fails verification, GNOME Files attempts to use an alternative directory named .Trash-$UID directly at the root of the drive (for example, .Trash-1000).

To maintain security:

  • GNOME Files verifies that this directory is owned exclusively by the acting user.
  • It sets or confirms strict directory permissions (typically 0700), denying read, write, or execute access to any other user account on the system.

Handling Non-POSIX Filesystems

Many external drives use filesystems such as FAT32, exFAT, or NTFS, which lack native POSIX ownership and permission models. In these cases, the Linux kernel assigns mounting permissions based on the active mount options. GNOME Files checks whether the current user is the effective owner of the mount point. If the filesystem does not support safe user isolation, GNOME Files protects user privacy by alerting the user that the file cannot be moved to the trash securely and prompts to permanently delete the file instead.