How Unrar Handles Extracting to a Mount Point

When extracting an archive to a mount point, the unrar utility relies on standard operating system file abstractions rather than managing partition boundaries directly. This article explains how unrar interacts with the Virtual File System (VFS), how it validates disk space on mounted storage, the limitations encountered with cross-device hard links, and the impact of specific mount options and non-POSIX filesystems during the extraction process.

Virtual File System Abstraction

unrar is a user-space application that interacts with directories through standard POSIX system calls such as opendir(), mkdir(), and open(). Because modern operating systems handle mounted filesystems through an abstraction layer like the Linux Virtual File System (VFS), unrar does not distinguish a mount point from any standard local directory.

When you target a mount point (for example, /mnt/storage), the kernel resolves the path and routes all subsequent write and read calls directly to the driver responsible for that mounted device. As long as the path exists and the executing user has write permissions, unrar initiates extraction immediately.

Free Space Checks

Before and during extraction, unrar calculates whether the destination has sufficient capacity to store the uncompressed data. It queries available disk space via the statvfs() system call using the destination path.

Because statvfs() is called against the targeted directory, the kernel returns the geometry and block counts of the mounted volume rather than the parent or root filesystem. This ensures that unrar correctly calculates limits based on the dedicated partition, preventing false out-of-space warnings or unexpected disk saturation on the root drive.

If an archive contains hard links, extracting to a mount point can introduce operational edge cases:

  • Internal Hard Links: If two files within the archive are hard-linked and both reside within the target mount point, unrar uses the link() system call, which succeeds because both files share the same filesystem.
  • External Links Across Boundaries: If an archive attempts to establish a hard link between a file on the root filesystem and a file inside the mount point, the kernel rejects the operation with an EXDEV (Invalid cross-device link) error. Hard links cannot span across different filesystems or block devices. In this scenario, unrar will typically output an error and either skip the link or create an independent duplicate copy of the file, depending on the extraction flags used.

Symbolic links (symlinks) do not face this limitation, as they store text-based paths rather than direct inode references. However, symlink creation can still be restricted if the mount point was mounted with specific security flags.

Mount Options and Permission Compatibility

The success of extracting file attributes—such as ownership, permissions, and timestamps—depends on the flags and filesystem type applied to the mount point:

  • Read-Only (ro): If the target device is mounted read-only, unrar fails immediately upon attempting to create the first file or directory with an EACCES or EROFS (Read-only file system) error.
  • Non-POSIX Filesystems (FAT32, exFAT, NTFS): When extracting to filesystems that do not natively support POSIX ownership (uid/gid) or permissions (chmod), unrar will quietly fail or warn when trying to apply original attributes. While the file contents are successfully written, ownership defaults to the mount-level options specified in /etc/fstab (such as uid=1000,gid=1000).
  • Filesystem Constraints: Extracting files with characters not supported by certain target filesystems (such as colons or question marks on NTFS/FAT) will cause unrar to report write errors unless renamed during extraction.
  • Execution Flags (noexec): If the mount point is mounted with noexec, unrar can still extract executable binaries, but the operating system will block their execution directly from that mount point.