Hubbry Logo
USB mass storage device classUSB mass storage device classMain
Open search
USB mass storage device class
Community hub
USB mass storage device class
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
USB mass storage device class
USB mass storage device class
USB mass storage device class
View on Wikipedia
from Wikipedia
A USB thumb drive and its cap, next to a 100 millimeter ruler for scale
USB flash drives typically implement the USB mass storage device class.

The USB mass storage device class (also known as USB MSC or UMS) is a set of computing communications protocols, specifically a USB Device Class, defined by the USB Implementers Forum that makes a USB device accessible to a host computing device and enables file transfers between the host and the USB device. To a host, the USB device acts as an external hard drive; the protocol sets interfaces with a number of storage devices.

Uses

[edit]
An action camera being accessed via mass storage device class

Devices connected to computers via this standard include:

Devices supporting this standard are known as MSC (Mass Storage Class) devices. While MSC is the original abbreviation, UMS (Universal Mass Storage) has also become common use.

Operating system support

[edit]

Most mainstream operating systems include support for USB mass storage devices; support on older systems is usually available through patches.

Microsoft Windows

[edit]

Microsoft Windows has supported MSC since Windows 2000. There is no support for USB supplied by Microsoft in Windows before Windows 95 and Windows NT 4.0. Windows 95 OSR2.1, an update to the operating system, featured limited support for USB. During that time, no generic USB mass-storage driver was produced by Microsoft (including for Windows 98), and a device-specific driver was needed for each type of USB storage device. Third-party, freeware drivers became available for Windows 98 and Windows 98SE, and third-party drivers are also available for Windows NT 4.0. Windows 2000 has support (via a generic driver) for standard USB mass-storage devices; Windows Me and all later Windows versions also include support.

Windows Mobile supports accessing most USB mass-storage devices formatted with FAT on devices with USB Host. However, portable devices typically cannot provide enough power for hard-drive disk enclosures (a 2.5-inch (64 mm) hard drive typically requires the maximum 2.5 W in the USB specification) without a self-powered USB hub. A Windows Mobile device cannot display its file system as a mass-storage device unless the device implementer adds that functionality. However, third-party applications add MSC emulation to most WM devices (commercial Softick CardExport and free WM5torage). Only memory cards (not internal-storage memory) can generally be exported, due to file-system issues; see device access, below.

The AutoRun feature of Windows worked on all removable media, allowing USB storage devices to become a portal for computer viruses. Beginning with Windows 7, Microsoft limited AutoRun to CD and DVD drives, updating previous Windows versions.[1]

MS-DOS

[edit]

Neither MS-DOS nor most compatible operating systems included support for USB. Third-party generic drivers, such as Duse, USBASPI, and DOSUSB, are available to support USB mass-storage devices. FreeDOS supports USB mass storage as an Advanced SCSI Programming Interface (ASPI) interface.

Classic Mac OS and macOS

[edit]

Apple's Mac OS 9 and macOS support USB mass storage; Mac OS 8.6 supported USB mass storage through an optional driver.[2]

Linux

[edit]

The Linux kernel has supported USB mass-storage devices since version 2.3.47[3] (2001, backported to kernel 2.2.18[4]). This support includes quirks and silicon/firmware bug workarounds as well as additional functionality for devices and controllers (vendor-enabled functions such as ATA command pass-through for ATA-USB bridges, used for S.M.A.R.T. or temperature monitoring, controlling the spin-up and spin-down of hard disk drives, and other options). Mobile devices running Android 6 or higher[5] also supports USB mass storage through dual-role USB on USB-C ports, and USB-OTG on older ports.

[edit]

Solaris has supported devices since its version 2.8 (1998), NetBSD since its version 1.5 (2000), FreeBSD since its version 4.0 (2000) and OpenBSD since its version 2.7 (2000). Digital UNIX (later known as Tru64 UNIX) has supported USB and USB mass-storage devices since its version 4.0E (1998). AIX has supported USB mass-storage devices since its 5.3 T9 and 6.1 T3 versions; however, it is not well-supported and lacks features such as partitioning and general blocking.[6]

Game consoles and embedded devices

[edit]

The Xbox 360 and PlayStation 3 support most mass-storage devices for the data transfer of media such as pictures and music. As of April 2010, the Xbox 360 (a) used a mass-storage device for saved games[7] and the PS3 allowed transfers between devices on a mass-storage device. Independent developers have released drivers for the TI-84 Plus and TI-84 Plus Silver Edition to access USB mass-storage devices.[8] In these calculators, the usb8x driver supports the msd8x user-interface application.

Device access

[edit]
A small, thin, gray box, with data card inserted in a bottom slot
USB card readers typically implement the USB mass storage device class.
See also: USB Attached SCSI

The USB mass-storage specification provides an interface to a number of industry-standard command sets, allowing a device to disclose its subclass. In practice, there is little support for specifying a command set via its subclass; most drivers only support the SCSI transparent command set, designating their subset of the SCSI command set with their SCSI Peripheral Device Type (PDT). Subclass codes specify the following command sets:

  1. Reduced Block Commands (RBC)
  2. SFF-8020i, MMC-2 (used by ATAPI-style CD and DVD drives)
  3. QIC-157 (tape drives)
  4. Uniform Floppy Interface (UFI)
  5. SFF-8070i (used by ARMD-style devices)
  6. SCSI transparent command set (use "inquiry" to obtain the PDT)

The specification does not require a particular file system on conforming devices. Based on the specified command set and any subset, it provides a means to read and write sectors of data (similar to the low-level interface used to access a hard drive). Operating systems may treat a USB mass-storage device like a hard drive; users may partition it in any format (such as MBR and GPT), and format it with any file system.

Because of its relative simplicity, the most common file system on embedded devices such as USB flash drives, cameras, or digital audio players is Microsoft's FAT or FAT32 file system (with optional support for long filenames). However, USB mass storage devices may be formatted with any other file system, such as NTFS on Windows NT, HFS Plus on macOS, ext2 on Linux, or Unix File System on Solaris or BSD. This choice may limit (or prevent) access to a device's contents by equipment using a different operating system. OS-dependent storage options include LVM, partition tables and software encryption.

In cameras, MP3 players and similar devices which must access a file system independent of an external host, the FAT32 file system is preferred by manufacturers. All such devices halt their file-system (dismount) before making it available to a host operating system to prevent file-system corruption or other damage (although it is theoretically possible for both devices to use read-only mode or a cluster file system). Some devices have a write-protection switch (or option) allowing them to be used in read-only mode.

Two main partitioning schemes are used by vendors of pre-formatted devices. One puts the file system (usually FAT32) directly on the device without partitioning, making it start from sector 0 without additional boot sectors, headers or partitions. The other uses a DOS partition table (and MBR code), with one partition spanning the entire device. This partition is often aligned to a high power of two of the sectors (such as 1 or 2 MB), common in solid state drives for performance and durability. Some devices with embedded storage resembling a USB mass-storage device (such as MP3 players with a USB port) will report a damaged (or missing) file system if they are reformatted with a different file system. However, most default-partition devices may be repartitioned (by reducing the first partition and file system) with additional partitions. Such devices will use the first partition for their own operations; after connecting to the host system, all partitions are available.

Devices connected by a single USB port may function as multiple USB devices, one of which is a USB mass-storage device. This simplifies distribution and access to drivers and documentation, primarily for the Microsoft Windows and Mac OS X operating systems. Such drivers are required to make full use of the device, usually because it does not fit a standard USB class or has additional functionality. An embedded USB mass-storage device makes it possible to install additional drivers without CD-ROM disks, floppies or Internet access to a vendor website; this is important, since many modern systems are supplied without optical or floppy drives. Internet access may be unavailable because the device provides network access (wireless, GSM or Ethernet cards). The embedded USB mass storage is usually made permanently read-only by the vendor, preventing accidental corruption and use for other purposes (although it may be updated with proprietary protocols when performing a firmware upgrade). Advantages of this method of distribution are lower cost, simplified installation and ensuring driver portability.

Design

[edit]

Some advanced hard disk drive commands, such as Tagged Command Queuing and Native Command Queuing (which may increase performance), ATA Secure Erase (which allows all data on the drive to be securely erased) and S.M.A.R.T. (accessing indicators of drive reliability) exist as extensions to low-level drive command sets such as SCSI, ATA and ATAPI. These features may not work when the drives are placed in a disk enclosure that supports a USB mass-storage interface. Some USB mass-storage interfaces are generic, providing basic read-write commands; although that works well for basic data transfers with devices containing hard drives, there is no simple way to send advanced, device-specific commands to such USB mass-storage devices (though, devices may create their own communication protocols over a standard USB control interface). The USB Attached SCSI (UAS) protocol, introduced in USB 3.0, fixes several of these issues, including command queuing, command pipes for hardware requiring them, and power management.

Specific USB 2.0 chipsets had proprietary methods of achieving SCSI pass-through, which could be used to read S.M.A.R.T. data from drives using tools such as smartctl (using the -d option followed by "chipset").[9] More recent USB storage chipsets support the SCSI / ATA Translation (SAT) as a generic protocol for interacting with ATA (and SATA) devices.[10] Using esoteric ATA or SCSI pass-through commands (such as secure-erase or password protection) when a drive is connected via a USB bridge may cause drive failure, especially with the hdparm utility.[11]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

USB mass storage device class

View on Grokipedia
from Grokipedia
The USB mass storage device class (MSC) is a standardized USB device class that defines protocols for mass storage devices—such as USB flash drives, external hard disk drives, and optical drives—to communicate with host systems over the USB bus, effectively emulating storage devices without requiring custom drivers on most operating systems. This class, assigned base class code 08h in USB interface descriptors, enables seamless integration of storage peripherals by supporting industry-standard command sets like , allowing hosts to perform read/write operations, format disks, and manage logical units as if the devices were directly attached. Developed by the (USB-IF), the MSC specification originated with its initial release on October 22, 1998 (Revision 1.0), coinciding with the early adoption of USB 1.1 for peripheral connectivity, and has undergone several updates to enhance compatibility and performance. Key revisions include 1.1 (2000) for refined transport protocols, 1.2 (2003) for updates including restriction of CBI transport and list of specifications, with bootability support added in a separate specification (USB Mass Storage Bootability, Revision 1.0, 2004), 1.3 (2008) for additional subclass definitions, and 1.4 (2010), which introduced the Protocol (UAS) for improved data throughput and command queuing on high-speed USB connections. A related 2013 addendum extended UAS support for bootable devices, ensuring MSC compliance in environments. As of 2025, the specification remains current with Revision 1.4 (2010), supplemented by the 2013 UASP bootability addendum, and continues to underpin compatibility for USB storage devices. The class supports multiple subclasses to accommodate diverse device types, including 06h for SCSI transparent commands (enabling direct -3 operations), 01h for Reduced Block Commands (RBC) in simplified storage like flash media, 02h for (MMC-5) in optical drives, and 04h for USB Floppy Interface (UFI) in legacy floppy controllers. Transport protocols include the widely used Bulk-Only (BOT, protocol 50h), which leverages bulk transfers for reliable data movement; the deprecated Control/Bulk/Interrupt (CBI) transport (protocols 00h/01h), limited to full-speed floppy drives; and UAS (protocol 62h), optimized for + with asynchronous notifications and multiple outstanding commands. These elements ensure broad interoperability, with MSC devices automatically recognized by host drivers in Windows, macOS, , and other systems via class-specific requests like Get Max LUN for multi-unit support.

Introduction

Definition and Purpose

The USB mass storage device class, designated by base class code 08h, is a USB device class standardized by the (USB-IF) specifically for mass storage devices that conform to its specifications. This class enables USB devices to emulate conventional block storage devices, such as hard disk drives, by transporting standard command sets, primarily , over the USB bus, thereby facilitating plug-and-play connectivity for and storage access without requiring proprietary host drivers. It primarily employs the bulk-only transport protocol to handle command, data, and status exchanges via bulk endpoints. Among its key benefits are vendor-neutral interoperability, which ensures compatibility across diverse device implementations; support for essential read and write operations; and native integration with host file systems for transparent data management. The initial overview document for the specification, version 1.0, was released on October 22, 1998, followed by the full specification details in version 1.1 on June 28, 2000.

History and Development

The USB Mass Storage Device Class (MSC) originated in the late 1990s as a standardized protocol within the USB 1.1 specification, released in , to enable seamless integration of storage devices over USB without relying on vendor-specific proprietary drivers that had previously complicated device compatibility and deployment. This development was driven by the need for a universal interface for mass storage peripherals, building on the foundational USB architecture established by the (USB-IF) to promote interoperability across diverse hardware ecosystems. The initial MSC Overview Specification version 1.0 was released on October 22, 1998, providing the core framework for bulk-only transport and control/bulk/interrupt (CBI) mechanisms tailored to storage devices. Version 1.1 followed on June 28, 2000, refining the specification for broader adoption under USB 2.0 enhancements. By version 1.2, released June 23, 2003, updates included an expanded list of supported command sets and restrictions on CBI usage to full-speed floppy drives, improving reliability and error management in transport protocols. The specification evolved further with version 1.3 in September 2008, incorporating features like MSC-Lock for secure access and IEEE 1667 compliance for key management, while version 1.4, finalized February 19, 2010, introduced the USB Attached SCSI Protocol (UAS) to leverage USB 3.0's higher speeds, released in 2008, for more efficient command queuing and data transfer. A 2013 addendum extended UAS support for bootable devices. The rapid proliferation of USB flash drives in the early , starting with commercial releases in 2000 offering capacities from 8 MB, significantly boosted MSC adoption by providing portable, plug-and-play storage that aligned with the class's standardized approach. The USB-IF played a pivotal role in this evolution by enforcing across USB revisions, ensuring legacy MSC devices remained functional on newer hosts and peripherals. In contemporary contexts, MSC has seen partial deprecation in certain modern devices, such as smartphones, where protocols like (MTP) and (PTP) are preferred for enhanced security and selective file access without exposing the entire filesystem.

Technical Specifications

Protocol and Transport Mechanisms

The USB Mass Storage Device Class primarily employs the Bulk-Only Transport (BOT) protocol, which leverages USB bulk transfers for efficient communication between the host and device, utilizing dedicated Bulk-In and Bulk-Out endpoints for data movement while relying on the default control pipe for initial setup and class-specific requests. This transport mechanism avoids the use of endpoints for core operations. BOT ensures reliable, asynchronous data transfer suitable for applications by segmenting operations into distinct phases: command issuance, optional data transfer, and status reporting. At the heart of the BOT protocol is the Command Block Wrapper (CBW), a 31-byte structure sent from the host to the device via the Bulk-Out endpoint to initiate a command; it includes a (43425355h), the transfer and direction, the logical unit number (LUN), and the command block itself (typically 16 bytes, accommodating commands). Following the CBW, if transfer is required, packets are exchanged using the appropriate bulk endpoint based on the specified direction and , ensuring alignment on USB packet boundaries to maintain protocol integrity. The sequence concludes with the Command Status Wrapper (CSW), a 13-byte response from the device via the Bulk-In endpoint, containing a (53425355h), the residual , and a status code (00h for success, 01h for failure, or 02h for phase error). Endpoint configuration in BOT follows standard USB practices, with the default pipe handling device enumeration, configuration, and class-specific requests such as the USB Mass Storage Reset; the Bulk-Out endpoint receives commands and outbound data, while the Bulk-In endpoint transmits inbound data and status. This setup supports multiple logical units if needed, addressed via the CBW's LUN field, and is designed for simplicity and broad host compatibility. Error handling in BOT emphasizes robustness through endpoint stalling: upon detecting issues like an invalid CBW signature, insufficient buffer space, or command failure, the device stalls the relevant bulk endpoints to signal the host, prompting clearance via a CLEAR_FEATURE request. For severe errors or protocol resets, the host issues a class-specific USB Reset request over the default pipe, after which it must clear halts on both bulk endpoints and potentially reinitialize the session to resume operations. These mechanisms ensure recovery without full device disconnection, maintaining session continuity. The BOT protocol was formalized in revision 1.0 of the USB Mass Storage Class Bulk-Only Transport specification, released in 1999 and aligned with USB 1.0 and 1.1 standards. Subsequent refinements have maintained its core structure while ensuring compatibility with USB 2.0 high-speed and USB 3.x SuperSpeed modes through the inherent scalability of bulk endpoints, allowing BOT devices to operate at higher data rates on modern hosts for . This enduring design has made BOT the transport for legacy and simple mass storage implementations across USB generations.

Command Sets and Data Transfer

The USB Mass Storage Device Class primarily employs a subset of commands to manage storage operations, encapsulated within the Bulk-Only Transport (BOT) protocol for compatibility with a wide range of block devices. Key commands in this subset, defined under subclass code 06h for transparent command set, include READ(10) for retrieving specified blocks of data, WRITE(10) for storing data to blocks, for querying device characteristics, and TEST UNIT READY for verifying device operational status. These commands are wrapped in a Command Block Wrapper (CBW) sent via the bulk-out endpoint, followed by data phases and a Command Status Wrapper (CSW) via the bulk-in endpoint, ensuring reliable transaction handling without command queuing. Optionally, devices may support ATA pass-through commands, such as those defined in the SCSI ATA Translation (SAT) standard, allowing direct issuance of ATA/ATAPI instructions through SCSI envelopes for compatibility with legacy IDE/SATA storage. This is typically implemented under the same SCSI transparent subclass, using commands like ATA PASS-THROUGH (16) to bridge protocols without altering the core USB transport. Data transfers in the class rely on USB bulk transfers for efficient movement of large blocks between host and device, utilizing dedicated bulk-in and bulk-out endpoints to handle directional flows—host-to-device for writes and device-to-host for reads. While BOT does not natively support scatter-gather at the protocol level, host controllers can implement scatter-gather DMA for non-contiguous memory buffers during these bulk operations, optimizing performance for fragmented accesses. Block sizes are standardized at 512 bytes for most devices to align with traditional sectoring, though modern implementations support larger logical block sizes up to 4096 bytes or more via extended commands like READ CAPACITY (16). During initialization, command response identifies the device as a direct-access block with peripheral device type 00h and peripheral qualifier 00b, indicating a connected, fully functional storage peripheral capable of . This , at least 36 bytes long, provides essential parameters like device type and version for host configuration. The class imposes limitations on advanced storage features; for instance, without protocol extensions, it lacks native support for caching, command queuing, or recovery mechanisms beyond basic SCSI sense codes, restricting throughput to sequential, single-command operations. BOT's design prioritizes simplicity and broad interoperability, capping logical units at 16 (including LUN 0) and prohibiting bidirectional data in a single transaction.

USB Attached SCSI (UAS) Enhancements

The (UAS) protocol, also known as USB Attached SCSI Protocol (UASP), was introduced in the USB Class specification revision 1.4 in 2010 to leverage capabilities as a high-performance alternative to the Bulk-Only Transport (BOT) protocol within the USB Class. Unlike BOT, which processes commands sequentially and mixes command, data, and status transfers on shared bulk endpoints, UAS employs a dedicated four-pipe model—separate endpoints for commands, status, data-in, and data-out—enabling asynchronous command queuing and pipelining to better utilize USB bus bandwidth. This design aligns with the Architecture Model (SAM-4), transporting standard commands over USB while leveraging USB for efficient data handling. Key enhancements in UAS include support for multiple outstanding commands, allowing multiple outstanding commands with task attributes such as SIMPLE, HEAD OF QUEUE, or ORDERED to manage execution priorities, with queue depth depending on device implementation. Pipelining reduces latency by eliminating the round-trip delays inherent in BOT's , where each command typically requires three bulk transfers. UAS also incorporates advanced functions, including ABORT TASK, CLEAR TASK SET, and LOGICAL UNIT RESET, which enable the host to or reset specific operations without affecting the entire device. Error recovery is improved through mechanisms that allow the host to detect and clean up incomplete transactions, such as data underruns, before proceeding with subsequent commands, enhancing reliability in high-speed environments. For compatibility, UAS devices must include a BOT-compatible alternate interface, enabling fallback to BOT mode on USB 2.0 hosts or systems lacking UAS support, ensuring broad while requiring explicit endorsement from both host controllers and devices for full UAS operation. Performance benefits are particularly evident in and later, offering significant performance improvements, particularly for random I/O and multi-command workloads, compared to BOT due to reduced overhead and parallel processing. UAS adoption has grown with devices, becoming standard for many high-speed storage enclosures, though it remains optional under the USB Class specification and is not explicitly mandated for USB 3.1 or later compliance.

Applications and Compatibility

Common Device Types

The USB mass storage device class (MSC) is widely implemented in primary storage devices that provide plug-and-play access to data via USB connections. USB flash drives, also known as thumb drives, represent one of the most ubiquitous examples, utilizing for compact, removable storage capacities ranging from gigabytes to terabytes. These devices adhere to the Bulk-Only protocol within the MSC specification, enabling seamless as block devices by host operating systems. External hard disk drives (HDDs) and solid-state drives (SSDs) connected via USB also commonly employ the MSC, offering high-capacity storage for backups and data transfer, with speeds enhanced by USB 2.0 or later interfaces introduced around 2000. Additionally, USB card readers for SD and microSD cards function under the MSC, allowing direct access to memory cards from cameras and mobile devices without proprietary drivers. In multimedia applications, the MSC facilitates storage access in devices like digital cameras and portable audio players. Many digital cameras from manufacturers such as support a "Mass Storage" USB mode, exposing internal memory or memory card contents as a removable disk for . MP3 players and portable media players often implement the MSC to present their internal storage partitions, enabling users to drag-and-drop audio files directly from a host computer, as seen in models from SanDisk that switch between MSC and other protocols for compatibility. Other device types leveraging the MSC include external optical drives and specialized USB peripherals. USB CD and DVD drives typically operate under the MSC using SCSI command sets, allowing read/write access to optical media as if connected internally. Some printers incorporate internal storage or USB host functionality but may expose firmware or temporary storage via MSC during driver installation or direct printing modes. Bootable USB keys, essentially configured USB flash drives, utilize the MSC for BIOS/UEFI booting, supporting live operating systems and recovery tools by presenting a bootable partition. The adoption of the USB MSC significantly contributed to the portable storage boom following 2000, coinciding with the commercialization of USB flash drives like the 8 MB ThumbDrive introduced that year. This standardization simplified data portability across devices, reducing reliance on proprietary connectors and driving market growth in . An early example of advanced features was the SanDisk U3 smart drive launched in 2005, which combined MSC storage with executable application support on the device itself. Operating systems generally recognize these MSC devices as generic block devices, integrating them into file explorers without additional configuration. Rare exceptions include the use of mobile phones to emulate USB mass storage devices for purposes such as BIOS updates. Older Android phones from the pre-2010s that supported USB Mass Storage mode could mimic a real drive when connected to a host. However, this capability is uncommon today due to its deprecation in modern Android versions. With a rooted modern Android phone and applications like DriveDroid, it is possible to emulate a USB drive or boot ISOs by setting up a virtual FAT32 image with the necessary files. This method is complicated, risky—potentially leading to bricking the motherboard if the flash fails mid-process—and not guaranteed to be detected by the BIOS. iPhones cannot emulate mass storage at all, relying instead on protocols like MTP or PTP. These methods are not recommended due to their complexity and risks.

Supported File Systems

USB mass storage devices present block-level storage to the host operating system, allowing the use of various file systems depending on the OS and compatibility requirements. The most universally supported formats are the FAT family, including FAT12, FAT16, and FAT32, which ensure broad interoperability across Windows, macOS, , and embedded systems due to their simplicity and legacy support. These formats are particularly common on pre-formatted USB devices, often paired with (MBR) partitioning for volumes up to 2 TB, though (GPT) is increasingly used for larger capacities to support modern booting. For handling files larger than 4 GB— a limitation of FAT32—exFAT provides cross-platform compatibility, with native read/write support in Windows (since Windows 7), macOS (since 10.6.5), and Linux (via kernel modules since version 5.4). NTFS, Microsoft's primary file system, offers advanced features like journaling and encryption but is primarily optimized for Windows, where it provides full read/write access; macOS and Linux offer read-only support natively, requiring third-party drivers (e.g., NTFS-3G or the kernel's ntfs3 module) for writing. Operating system-specific file systems further influence compatibility. On macOS, HFS+ (Hierarchical File System Plus) and APFS (Apple File System) are native, with full support for USB devices formatted in these schemes, though they lack native readability on Windows without additional software. natively supports , , and for USB storage, enabling efficient use in environments, but these formats are not readable on Windows or macOS without extensions. Cross-platform limitations often necessitate FAT32 or for shared use, as mismatched formats can lead to inaccessible data or require reformatting. Partitioning schemes like MBR and GPT are handled at the block level via the USB Mass Storage Class's emulation, with devices typically shipping with a single MBR-partitioned FAT32 volume for maximum compatibility. Compatibility issues arise from write protection modes, which some devices enforce to prevent accidental overwrites, and the need for proper ejection protocols—such as Windows' "Safely Remove Hardware" or Linux's umount command—to avoid file system corruption during removal. Failure to eject safely can result in data loss, particularly on non-journaled systems like FAT.

Operating System Integration

Microsoft Windows and MS-DOS

Microsoft Windows introduced limited support for USB mass storage devices with the release of Windows 95 OSR 2.1 in 1996, which included a USB supplement update that enabled basic compatibility for certain USB peripherals, though mass storage functionality remained restricted and required specific hardware configurations. Windows 98 First Edition and lacked native USB mass storage drivers, necessitating third-party solutions such as vendor-specific or universal drivers to enable recognition of USB storage devices like flash drives and external hard disks. In contrast, Windows 98 Second Edition provided partial native support for USB hard drives but still required third-party drivers for broader compatibility, including flash media. Native support for USB mass storage devices became standard starting with Windows 2000 in 2000, utilizing the USBSTOR.sys kernel-mode driver to handle Bulk-Only Transport (BOT) protocol devices and automatically enumerate them as removable disks. This driver stack persisted through subsequent versions, including Windows XP and Vista, providing seamless integration for FAT and NTFS file systems on USB storage. In Windows 7, released in 2009, Microsoft disabled AutoRun functionality for non-optical removable media, including USB mass storage devices, to mitigate security risks from autorun-based malware, shifting to a prompt-based AutoPlay dialog for user-initiated actions. MS-DOS, including versions up to 6.22, offered no native USB support due to its pre-USB architecture, requiring third-party for any USB access. Early solutions included the DUSE driver package around 1999, which provided basic USB host controller and emulation for DOS environments. ASPI-based , such as USBASPI.sys, emerged as a common approach, layering SCSI command emulation over USB transports to treat devices as standard block devices accessible via tools like or FORMAT. Modern DOS-compatible systems, such as , continue to rely on these third-party drivers for support, with packages like USBASPI enabling compatibility with contemporary and even some devices on legacy hardware, provided the supports USB legacy mode. However, older Windows versions like 95 and 98 were inherently limited to USB 1.1 full-speed operation at 12 Mbps, even when connected to ports, due to driver and protocol constraints that prevented higher-speed negotiation. (UAS) enhancements, which improve concurrent command processing and transfer efficiency for modern storage, were introduced natively in in via the UASPSTOR.sys driver, requiring compatible hardware and falling back to BOT for unsupported devices.

Apple Systems (Classic Mac OS and macOS)

Support for the USB device class in began with version 8.6, released in February 1999, where it required an optional driver known as USB Mass Storage Support 1.3.5, provided by Apple in June 1999 to enable compatibility with USB storage devices. This driver allowed basic read and write access to mass storage devices but was not included by default in the operating system. With the release of Mac OS 9.0 in October 1999, support became fully integrated, eliminating the need for separate installation and providing seamless recognition of USB devices without additional software. macOS, starting with version 10.0 in March 2001, introduced native support for the USB mass storage device class, allowing direct compatibility with devices without requiring third-party drivers. This integration extended to file systems such as HFS+ from the outset, with APFS support added in 10.13 in 2017, enabling efficient handling of modern USB drives formatted accordingly. USB mass storage devices automatically mount upon connection, appearing in the Finder sidebar and /Volumes directory for easy access and management. Additionally, macOS utilizes USB drives for Time Machine backups, which require formatting in HFS+ (Journaled) or APFS to ensure compatibility and optimal performance. In Apple's mobile ecosystems, and gained support for USB mass storage via USB-C On-The-Go (OTG) functionality starting with the 2018 iPad Pro models, allowing users to connect external drives directly to the Files app for reading and writing data. This feature expanded accessibility for storage expansion on compatible devices with USB-C ports. Early implementations in both and initial macOS versions were limited to USB 1.1 speeds, capping transfer rates at approximately 12 Mbps due to the hardware constraints of contemporary Macintosh systems. Native support for NTFS-formatted drives is read-only across all versions of macOS, necessitating third-party software for write access to maintain compatibility with Windows-originated storage.

Linux and Unix-like Systems

In Linux, support for the USB mass storage device class is provided by the usb-storage kernel module, which was introduced in kernel version 2.3.47 in February 2000. This module emulates commands over USB, allowing mass storage devices to appear as standard block devices to the operating system. Portions of the USB subsystem, including usb-storage, were backported to the stable 2.2 series starting with kernel 2.2.18 in December 2000, enabling broader adoption on production systems. Enhanced support for the (UAS) protocol, which improves performance for modern and later devices by allowing concurrent command execution, was added in kernel 2.6.31 in September 2009. UAS devices are detected and utilized automatically when compatible hardware is present, falling back to the traditional Bulk-Only Transport (BOT) via usb-storage otherwise. In contemporary distributions, device enumeration and mounting are handled dynamically by , which triggers rules to mount filesystems on insertion, often integrating with desktop environments like or for user-friendly access. Among other Unix-like systems, Solaris introduced USB mass storage support in version 2.8 (Solaris 8) with the 10/00 maintenance release in 2000, covering removable devices such as Zip drives and early flash media through the scsa2usb driver. NetBSD added umass driver support for USB mass storage in release 1.5 in December 2000, enabling SCSI emulation for disks, CD-ROMs, and similar peripherals. FreeBSD included initial umass support in version 4.0, released in March 2001, with compatibility for Bulk-Only and Control/Bulk/Interrupt transports. OpenBSD followed in version 2.7 in June 2000, providing umass for mass storage class devices via SCSI command passthrough. IBM AIX gained USB support starting with version 5.3 Technology Level 5300-09 in 2007, though limited to devices up to 2 TB capacity and USB 1.1 speeds, with later expansions for larger volumes in subsequent releases. For mobile variants, Android deprecated USB in device mode after early versions, switching to MTP/PTP for connections to PCs. Support for USB host mode, allowing direct access to attached devices via OTG, was added in Android 3.1. Common user-space tools for managing USB mass storage on these systems include dd for low-level disk imaging and cloning, and fsck for filesystem integrity checks, applicable across and BSD variants for tasks like or verification. These tools interact with the emulated layer without requiring device-specific configurations.

Embedded and Gaming Platforms

In gaming consoles, USB mass storage support has been implemented to enable storage expansion for saves, media, and compatible games, though capabilities vary by platform. The introduced official USB flash drive support through a system update released on April 6, 2010, allowing up to 16 GB of usable space for profiles, game saves, and arcade titles on compatible drives of at least 1 GB capacity. The natively supports USB mass storage devices formatted in FAT32 for media playback, game installations via files, and external HDDs up to 2 TB. Similarly, the and provide native USB extended storage for PS4 games (playable directly from or later drives of 250 GB to 8 TB) and media files, though PS5 games require transfer to internal storage for execution. For the , the dock's USB ports primarily support peripherals like wired LAN adapters and controller charging, with no official mass storage functionality for game or media expansion; storage relies on microSD cards instead. Embedded platforms, including routers, smart TVs, and set-top boxes, leverage USB mass storage for storage expansion in resource-constrained environments. Routers running like support USB storage on models with USB ports, enabling (NAS) for when the firmware includes core USB and storage modules. Smart TVs and set-top boxes, particularly those based on , allow USB drives (formatted as FAT32 or ) to expand internal storage for apps, media, and downloads, with devices recognizing drives up to several terabytes via USB 2.0 or 3.0 ports. Limitations in these platforms often stem from hardware and firmware constraints. Early Xbox consoles, such as the original model, provided limited USB 1.1 support primarily for memory units and media reading, with drives over 4 GB emulated as read-only memory cards due to BIOS restrictions and slow transfer rates unsuitable for full mass storage. Additionally, USB 2.0's power delivery—capped at 500 mA for high-power devices—poses challenges in embedded systems, where insufficient port power may prevent operation of power-hungry HDDs without external supplies, favoring low-power flash drives or SSDs. Representative examples illustrate robust integration in open embedded ecosystems. Android TV devices, such as those from or third-party manufacturers, fully support USB for adoptable storage, allowing users to format drives as internal or portable partitions to host apps and media directly. The Raspberry Pi series, running the , provides comprehensive USB host support for devices through built-in drivers like usb-storage, enabling seamless mounting of USB drives as block devices for file systems like or FAT32 on models with USB 2.0/3.0 ports.

Access Methods and Limitations

Device Enumeration and Access Protocols

The enumeration of a USB device begins when the host detects the connection via the USB bus, triggering the standard USB device discovery process as defined in the USB 2.0 specification. During this phase, the device presents its descriptors, including the configuration descriptor where the interface descriptor specifies the base class code 08h for . Within the interface descriptor, the subclass code identifies the command set, with 06h denoting the SCSI transparent command set for broad compatibility with commands. The protocol code further specifies the transport mechanism, such as 50h for Bulk-Only Transport (BOT) or 62h for (UAS). Upon successful , the host's software—detailed in operating sections—assigns a drive letter or mount point to make the device accessible as a block storage volume. Access to the device occurs through transparent pass-through of commands over the specified transport protocol, allowing the host to issue standard commands like READ(10) or WRITE(10) without protocol-specific modifications. For BOT, commands are encapsulated in bulk-only packets using Command Block Wrappers (CBW) and Command Status Wrappers (CSW), while UAS uses a more efficient command queuing model with separate pipes for commands, data, and status. Read-only modes can be enforced or indicated via the Removable Medium Bit (RMB) in the response, where a value of 1 signals that may support write-protection mechanisms. Proper dismount and ejection procedures ensure data integrity by flushing write caches before physical removal, leveraging USB's inherent hot-plug capabilities for safe connection and disconnection without system reboot. The host typically issues the SCSI SYNCHRONIZE CACHE command (opcode 35h) to commit pending writes to the medium, followed by optional ejection commands like START STOP UNIT (opcode 1Bh) for media trays. This process mitigates risks from abrupt removal in hot-plug scenarios, where the USB bus reset or device removal event triggers host-side unmounting. Multi-LUN support enables a single USB mass storage device to expose multiple independent storage units, such as in multi-slot card readers, with logical unit numbers (LUNs) ranging from 0 to a maximum of 15 for up to 16 total units. The host queries the maximum supported LUN using the vendor-specific Get Max LUN request (bRequest FEh) during or after , allowing targeted access to each LUN via commands prefixed with the LUN identifier. This feature enhances device versatility without requiring multiple physical USB connections.

Security and Access Restrictions

USB mass storage devices pose significant security risks due to their ability to facilitate propagation and unauthorized data access. One primary concern is the exploitation of autorun features in operating systems, where infected devices can automatically execute malicious code upon insertion, spreading worms or trojans across networks. This vulnerability was particularly prevalent in earlier Windows versions but was largely mitigated starting with , which disabled AutoRun support for non-optical like USB drives to prevent such automatic executions. Additionally, can infect drives through user interaction, such as opening contaminated files, leading to persistent threats that replicate to other connected devices. In shared environments, such as offices or public kiosks, these devices enable data leakage, where sensitive information is inadvertently copied or exfiltrated without detection, exacerbating risks in multi-user settings. To counter these threats, various restrictions and protective measures have been implemented. Many USB drives feature hardware write-protection switches that physically prevent data modification, ensuring read-only access and safeguarding against or accidental overwrites. Software-based read-only emulation can also be enforced, configuring the device to appear immutable to the host system while allowing selective access. In enterprise settings, policies often block USB entirely or restrict it to approved devices, using tools like in Windows to deny access and prevent unauthorized connections, thereby reducing the in corporate networks. Contemporary developments address these issues through alternative protocols and enhanced . The shift toward the (MTP) for media devices, rather than full class (MSC), limits exposure by avoiding the mounting of the entire storage volume as a drive letter, which circumvents autorun risks and provides better control over file access. Furthermore, support via file systems like enables full-volume protection on USB drives, requiring authentication to access data and mitigating theft or loss scenarios. A notable incident highlighting these vulnerabilities was the 2010 worm, which leveraged infected USB drives to infiltrate air-gapped Iranian nuclear facilities, demonstrating how MSC can propagate sophisticated across isolated systems. As of 2025, these risks persist in industrial and operational technology (OT) settings. The Honeywell 2025 Cyber Threat Report indicates that 25% of incidents involved USB plug-and-play events, with a 3,000% increase in detections of the W32.Ramnit worm on industrial networks. NIST's draft SP 1334 (July 2025) provides guidance on mitigating risks from portable storage media in OT environments through secure physical and logical access controls, scanning, and usage policies. Rare exceptions exist where mobile phones can emulate USB mass storage devices for specific uses, such as BIOS updates on computers, though these methods are uncommon, complex, and carry significant risks. Older Android devices from the pre-2010s era could natively support USB Mass Storage mode to mimic a real drive, but this capability has been deprecated in modern Android versions in favor of MTP. On rooted Android phones, applications like DriveDroid can emulate a USB drive by creating a virtual FAT32 image containing the necessary files, potentially allowing detection as a bootable device during BIOS updates. However, such emulation is not guaranteed to be detected by all BIOS firmware, requires technical expertise, and poses risks including potential bricking of the motherboard if the update process fails mid-flash. iPhones cannot emulate mass storage at all due to iOS restrictions, relying instead on protocols like MTP or PTP. These methods are not recommended for critical operations like BIOS updates due to their unreliability, security vulnerabilities (e.g., exposing the phone to host-side malware or vice versa), and potential for hardware damage; dedicated USB drives are advised for such purposes. For further details on device types supporting emulation, see the Applications and Compatibility section.

References

  1. https://www.usb.org/sites/default/files/Mass_Storage_Specification_Overview_v1.4_2-19-2010.pdf
  2. https://www.usb.org/defined-class-codes
  3. https://www.usb.org/sites/default/files/usb_msc_boot_1.0.pdf
  4. https://www.usb.org/document-library/usb-mass-storage-class-specification-uasp-bootability-v10-and-adopters-agreement
  5. https://www.usb.org/documents?search=&type%255B0%255D=55&items_per_page=50
  6. https://www.usb.org/document-library/mass-storage-class-specification-overview-14
  7. https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/supported-usb-classes
  8. https://www.usb.org/sites/default/files/usbmassbulk_10.pdf
  9. https://www.intel.com/content/dam/www/public/us/en/documents/articles/usb-two-decades-of-plug-and-play-article.pdf
  10. https://www.computerhistory.org/storageengine/portable-personal-storage-devices/
  11. https://www.howtogeek.com/192732/android-usb-connections-explained-mtp-ptp-and-usb-mass-storage/
  12. https://www.usb.org/sites/default/files/documents/usb_debug_class_rev_1_0_final_0.pdf
  13. https://docs.silabs.com/protocol-usb/1.5.1/protocol-usb-msc-scsi/
  14. https://ssd.borecraft.com/documents/UASP.pdf
  15. https://www.t10.org/ftp/t10/document.08/08-221r0.pdf
  16. https://www.drivedroid.io/
  17. https://forum.xda-developers.com/t/use-phone-as-bootable-windows-installer.740140/
  18. https://support.apple.com/guide/disk-utility/file-system-formats-dsku19ed921c/mac
  19. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/5/html/deployment_guide/sect-using_the_mount_command-mounting
  20. https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11
  21. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/considerations_in_adopting_rhel_9/assembly_file-systems-and-storage_considerations-in-adopting-rhel-9
  22. https://support.apple.com/en-us/101830
  23. https://support.microsoft.com/en-us/topic/usb-and-sd-storage-media-correctly-log-on-storage-media-and-enable-write-caching-fc436b8c-a19b-ce79-e17e-5af31a26cef8
  24. https://retrocomputing.stackexchange.com/questions/7995/how-to-use-usb-flash-drives-with-windows-98-se
  25. https://learn.microsoft.com/en-us/windows-hardware/drivers/install/identifiers-generated-by-usbstor-sys
  26. https://www.itwriting.com/blog/1372-microsoft-disabling-usb-autorun-in-windows-7-rc.html
  27. https://www.bootdisk.com/usb.htm
  28. https://hddguru.com/software/2006.02.09-USBASPI-MS-DOS-Driver/
  29. https://www.dosdays.co.uk/topics/usb_support.php
  30. https://www.lifewire.com/what-is-usb-1-1-2626036
  31. https://download.microsoft.com/download/7/d/7/7d7783ad-028b-4ca6-ac35-fdad2caee510/usb-attached-scsi-best-practices-windows-8.docx
  32. https://classicmacs.sourceforge.io/downloads/update/usbmass135.html
  33. https://www.macintoshrepository.org/161-usb-mass-storage-1-3-5
  34. https://support.apple.com/guide/mac-help/connect-storage-devices-mac-mchl027f1d66/mac
  35. https://support.apple.com/guide/mac-help/types-of-disks-you-can-use-with-time-machine-mh15139/mac
  36. https://support.apple.com/guide/ipad/external-storage-devices-ipad75b7b23f/ipados
  37. https://discussions.apple.com/thread/1978111
  38. https://apple.stackexchange.com/questions/188197/ntfs-support-for-mac
  39. https://ftp.riken.jp/Linux/kernel/v2.3/patch-html/patch-2.3.47/linux_drivers_usb_usb-storage.h.html
  40. http://www.linux-usb.org/USB-guide/x498.html
  41. http://www.linux-usb.org/
  42. https://kernelnewbies.org/Linux_2_6_31
  43. https://docs.oracle.com/cd/E19455-01/806-7502/6jgce01v5/index.html
  44. https://man.netbsd.org/NetBSD-1.5/usb.4
  45. https://man.freebsd.org/cgi/man.cgi?query=umass&sektion=4
  46. https://www.openbsd.org/plus27.html
  47. https://www.ibm.com/docs/en/aix/7.3.0?topic=management-usb-device-support
  48. https://source.android.com/docs/core/storage/config
  49. https://news.xbox.com/en-us/2010/03/26/usb-memory-support-for-the-xbox-360-coming-april-6th/
  50. https://gaming.stackexchange.com/questions/403341/is-there-a-total-external-storage-limit-for-a-playstation-3
  51. https://www.playstation.com/en-us/support/hardware/ps5-extended-storage/
  52. https://www.nintendo.com/en-gb/Support/Nintendo-Switch/FAQ/What-can-I-connect-to-the-USB-port-on-the-Nintendo-Switch-dock-/What-can-I-connect-to-the-USB-port-on-the-Nintendo-Switch-dock-1207751.html
  53. https://wiki.dd-wrt.com/wiki/index.php/USB_storage
  54. https://support.google.com/androidtv/answer/6299083?hl=en
  55. https://consolemods.org/wiki/Xbox:USB_Device_Compatibility_List
  56. https://www.usb.org/sites/default/files/Embedded%2520USB2%2520Version%25202.0%2520Supplement%2520to%2520the%2520USB%25202.0%2520Specification_0.pdf
  57. https://www.honeywell.com/us/en/press/2025/06/ransomware-attacks-targeting-industrial-operators-surge-46-percent-in-one-quarter-honeywell-report-finds
  58. https://csrc.nist.gov/pubs/sp/1334/ipd
  59. https://stackoverflow.com/questions/25960111/android-usb-mass-storage-deprecated-why
  60. https://drivedroid.io/
  61. https://discussions.apple.com/thread/251265958
Add your contribution
Related Hubs
User Avatar
No comments yet.