Storage and File Management

This section is the primary entry point for Launcher storage from an administrator perspective. It explains how Files tab storage (Storage Contexts), structured mounts, Turbo Drive, and file handling policies fit together and points to the deeper reference pages when you need full schemas or platform posture details.

Launcher storage is built from four pillars:

• Storage Contexts (Files tab storage) – local Secure Sandbox roots configured under runtime.files.contexts.
• Structured mounts – host paths (including Turbo Drive folders) mapped into containers at launch time.
• Turbo Drive cloud storage – provider-backed cloud storage and SMB shares exposed as a virtual filesystem.
• File handling & DLP – file type definitions, associations, and motion controls enforced by policy.

Not sure whether to use Storage Contexts or structured mounts for a scenario? See Storage Contexts vs Structured Mounts for a side-by-side comparison.

Before configuring Storage Contexts, ensure your local volumes meet the posture requirements described in Secure Sandbox Storage.

What You'll Learn

• How Storage Contexts, structured mounts, Turbo Drive, and file handling fit together
• How to configure Files tab roots and structured mounts with validation and precedence
• How to apply posture requirements for Secure Sandbox storage

---

1. Storage Persistence Model

To explain "Sandbox storage" to users, distinguish between the container's private layer and the mapped paths that pass through to the host.

Scope	Content	Persistence
Shared Storage (User Data)	Mapped Folders: Standard user folders (Documents, Desktop, Downloads) and mapped drives (T:).	Persistent. These paths map directly to the host filesystem. Files saved here survive session resets.
Session Storage (App State)	Container Overlay: Registry keys, AppData configuration, installed plugins, and writes to unmapped system folders (e.g., C:\Program Files).	Ephemeral. Isolates the app state from the host. ⚠️ Wiped if the user selects "Delete Session".

Administrator Note: Because standard user folders are mapped to Shared Storage in the default policy, "Delete Session" acts as a safe "Factory Reset" that fixes application glitches without deleting user documents.

---

2. Storage Contexts (Files tab storage)

Storage Contexts define the Files tab roots under runtime.files.contexts. Use them to choose which secure local folders are visible in the Files tab and how they map into containers before you layer on structured mounts or cloud storage.

1.1 Configuration shape

{
  "configuration": {
    "launch": {
      "runtime": {
        "files": {
          "defaultContextId": "personal",
          "contexts": [
            {
              "id": "personal",
              "label": "Personal",
              "source": "<SECURE_LOCAL_PATH>",
              "destination": "@DOCUMENTS@\\SandboxPersonal",
              "options": ["read-write"]
            }
          ]
        }
      }
    }
  }
}

• source must resolve to a local Secure Sandbox storage path (no UNC/NFS/SMB or Turbo Drive paths).
• destination is the container path where the Files tab root appears.
• options controls read/write behavior for that context.

1.2 Platform examples

Use platform-appropriate paths for source:

• Windows (NTFS/ReFS):

  • "source": "@DOCUMENTS@\\SandboxPersonal"
  • "source": "D:\\TurboSandbox\\Team"

• macOS (APFS):

  • "source": "~/TurboSandbox/Personal"
  • "source": "/Volumes/SecureSandbox/Team"

• Linux (ext4/XFS/btrfs):

  • "source": "~/TurboSandbox/personal"
  • "source": "/mnt/secure_sandbox/team"

1.3 Key rules

• Storage Contexts are local Secure Sandbox storage only.
• Do not use UNC/NFS/SMB or Turbo Drive paths as Storage Context roots.
• Each context is posture-validated (filesystem type, encryption, permissions).

See detailed guidance:

• Runtime Configuration – Files Storage
• Secure Sandbox Storage
• Mounts & Shared Storage – Files tab storage

---

3. Structured mounts for application launches

Structured mounts map host paths into containers at launch time and are authored in policy:

• Global: configuration.launch.mounts
• Per-app: apps[].modifications.mounts
• Per-profile: apps[].profiles[].mounts

Mount shape:

{
  "name": "Desktop",
  "source": "@DESKTOP@",
  "destination": "@DESKTOP@",
  "options": ["read-write"]
}

Use structured mounts to:

• Expose local storage to specific apps/profiles.
• Provide consistent container paths via well-known tokens (for example, @DOCUMENTS@).
• Apply ABAC requirements on visibility.abac.requirements.

Precedence and merging are covered under:

• Mounts & Shared Storage
• Merging & Precedence – Mounts

---

4. Turbo Drive (cloud storage integration)

Turbo Drive exposes provider-backed cloud storage and SMB shares as a virtual filesystem:

• Windows: T:
• macOS: ~/Library/CloudStorage/Turbo Drive
• Linux: /mnt/tdrive

Use structured mounts to surface Turbo Drive folders inside containers instead of configuring them as Storage Context roots.

Example: Global OneDrive Documents mount (Windows)

{
  "configuration": {
    "launch": {
      "mounts": [
        {
          "name": "OneDriveDocs",
          "source": "T:\\OneDrive\\Tenants\\contoso.onmicrosoft.com\\Users\\{User.UPN}\\Documents",
          "destination": "@DOCUMENTS@\\Cloud\\OneDrive",
          "options": ["read-write"]
        }
      ]
    }
  }
}

Equivalent mounts on macOS and Linux use the Turbo Drive mount point on each platform.

On macOS, use the ~/Library/CloudStorage/Turbo Drive namespace for the source path:

{
  "configuration": {
    "launch": {
      "mounts": [
        {
          "name": "OneDriveDocs",
          "source": "~/Library/CloudStorage/Turbo Drive/OneDrive/Tenants/contoso.onmicrosoft.com/Users/{User.UPN}/Documents",
          "destination": "@DOCUMENTS@/Cloud/OneDrive",
          "options": ["read-write"]
        }
      ]
    }
  }
}

On Linux, use the /mnt/tdrive namespace for the source path:

{
  "configuration": {
    "launch": {
      "mounts": [
        {
          "name": "OneDriveDocs",
          "source": "/mnt/tdrive/OneDrive/Tenants/contoso.onmicrosoft.com/Users/{User.UPN}/Documents",
          "destination": "@DOCUMENTS@/Cloud/OneDrive",
          "options": ["read-write"]
        }
      ]
    }
  }
}

Scope mounts appropriately:

• Global for common folders.
• Per-app for app-specific stores.
• Per-profile for role-specific access (for example, editors vs viewers).

Use ABAC on visibility.abac.requirements to restrict mounts by user attributes (for example, m365Licensed=true, role=editor).

See:

• Cloud Storage Integration (Turbo Drive)
• Mounts & Shared Storage – Cloud storage

---

5. File types, associations, and file operations

File handling is controlled by:

• fileTypes[] – Defines file types by extension, MIME type, or protocol.
• fileAssociations[] – Routes verbs (preview, open, edit, print) to providers or apps.
• files[] – Policies for file operations (list/import/export/open/delete).

Typical workflow:

1. Define file types (for example, pdf, docx, url) with matching rules.
2. Map file types to default preview/open providers with fileAssociations.
3. Gate file operations (import, export, open, delete) via files policies.
4. Use app capabilities and ABAC to constrain which apps handle sensitive file types.

See: File Handling

---

6. Secure Sandbox storage posture

The Secure Sandbox storage model requires:

• Local, posture-validated volumes (NTFS/ReFS on Windows, APFS on macOS, ext4/XFS/btrfs on Linux).
• Encryption at rest where required (for example, BitLocker, FileVault/APFS encryption, LUKS or equivalent).
• Hardened permissions at the Storage Context root.
• Rejection of UNC/NFS/SMB paths and unsupported filesystems (for example, FAT/exFAT, ephemeral tmpfs).

See: Secure Sandbox Storage

7. Troubleshooting storage

Use these references when Storage Contexts, mounts, or cloud storage are not behaving as expected:

• Files tab and Storage Contexts – Files Troubleshooting
• Files UI behavior (end-user view) – Files Tab
• Structured mounts and Turbo Drive mounts – see troubleshooting notes in Mounts & Shared Storage and Cloud Storage Integration
• Runtime posture failures and audit – see posture checks in Runtime Configuration and audit behavior in Security Best Practices

When adopting a fail-closed posture, validate new storage configurations in a test environment first so posture failures and cloud connectivity issues are surfaced before rollout.