Mounts & Shared Storage

Understand how the Launcher uses mounts for two different purposes:

• Files tab storage via Storage Contexts (configuration.launch.runtime.files.contexts)
• Structured mounts for application launches (policy‑authored, validated, precedence‑aware)

For storage provider namespaces (OneDrive, Dropbox, SMB) and platform-specific Turbo Drive paths, see Cloud Storage Integration (Turbo Drive).

What You'll Learn

• The difference between Files shared storage vs structured mounts
• Where to configure each (runtime vs policy objects)
• How precedence and validation work
• Best practices to avoid conflicts

---

Overview

A mount maps a host path into the container runtime at a destination path with optional access flags.

Structured mount shape (preferred for policy authoring):

{
  "name": "Desktop",                   // optional identity key used for merge/tie-breaks
  "source": "@DESKTOP@",               // host path; supports well-known tokens and environment variables
  "destination": "@DESKTOP@",          // container path inside the runtime
  "options": ["read-write"]            // allowed: "read-write", "read-only"
}

Well‑known tokens:

• "@DESKTOP@", "@DOWNLOADS@", "@DOCUMENTS@", "@PICTURES@", "@MUSIC@", "@VIDEOS@"
• Windows environment variables can be used in paths (e.g., "%LOCALAPPDATA%\MyApp\Logs").

Storage Contexts vs Structured Mounts

Use this table as the canonical comparison between Files tab Storage Contexts and policy-authored structured mounts.

Dimension	Storage Contexts (Files tab)	Structured mounts (app/profile launches)
Primary purpose	Define the Files tab root(s) so users can browse, import, and manage files in the Secure Sandbox.	Map host paths into containers at launch time for specific apps/profiles.
Where configured	configuration.launch.runtime.files.contexts under runtime.	configuration.launch.mounts, apps[].modifications.mounts, apps[].profiles[].mounts in policy.
Visible in UI	Drives the Files tab context picker and file browser.	Does not change the Files tab. Affects what paths are visible inside the running app/container.
Allowed sources	Local Secure Sandbox storage only. Paths must resolve to local, posture-validated volumes (no UNC/NFS/SMB, no Turbo Drive paths).	Any policy-approved host path, including Secure Sandbox folders, Turbo Drive namespaces (T:, ~/Library/CloudStorage/Turbo Drive, /mnt/tdrive), and other allowed local paths.
Typical use cases	Define "Personal", "Team", or similar roots for the Files tab; ensure storage lives on compliant local volumes.	Give an app read/write or read-only access to specific folders; pin stable locations like @DOCUMENTS@ inside containers; scope access per app/profile.
Cloud storage	Never point a Storage Context at cloud or network storage (including Turbo Drive).	Use structured mounts to map Turbo Drive provider folders (OneDrive, Dropbox, SMB) into containers.
Scope & precedence	Global runtime setting; contexts are validated individually and selected via defaultContextId or user choice.	Global, per-app, and per-profile mounts merge with precedence rules (see Merging & Precedence — Mounts).
Security posture checks	Strong posture validation (filesystem type, encryption, permissions, local-only paths). Misconfigurations typically block Files tab usage.	Mounts are validated against configuration templates/allowlists (sources, destinations, options) and ABAC rules; failures hide or deny the mount but do not redefine Files tab roots.
Mental model	"Where the Files tab lives."	"What extra folders this app/profile sees inside its container."

Files tab storage (Storage Contexts)

The Files tab displays one or more Storage Contexts configured via policy at configuration.launch.runtime.files.contexts. Each Storage Context defines a root directory that is securely mapped into the container. Users cannot navigate above the selected context’s root.

Requirements:

• Define at least one Storage Context under configuration.launch.runtime.files.contexts.
• Optional: configuration.launch.runtime.files.defaultContextId selects the initially active context; otherwise the first visible context is used.

Example (configuration shape):

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

Use platform-appropriate values for <SECURE_LOCAL_PATH> (for example, a local Documents subfolder or a path on a Secure Sandbox volume). See Secure Sandbox Storage for platform-specific examples and posture requirements.

Notes:

• Contexts are independently validated for security posture and visibility; unavailable contexts are indicated in the UI.
• After fixing configuration, use the Files tab Retry to reload.

See also:

• Files UI and behavior
• Runtime Configuration
• Files Troubleshooting

Security best practices (Storage Contexts)

• Keep Storage Context source paths on local Secure Sandbox storage volumes (not UNC/NFS/SMB or other network paths).
• Ensure volumes meet your filesystem, encryption, and permission posture requirements.
• Use enterprise configuration templates (allowedSourcePatterns) and removable media policy when applicable.

See full posture requirements and platform examples in Secure Sandbox Storage

Structured mounts for application launches (preferred)

Use policy‑authored structured mounts to map host paths into application containers with validation and deterministic precedence.

Where to define:

• Global (all launches): configuration.launch.mounts
• Per‑app (when that app launches): apps[].modifications.mounts
• Per‑launch profile (only when that launch profile is selected): apps[].profiles[].mounts

Learn more:

• Authoring and examples: Mounts & Shared Storage
• Precedence and merging: Merging & Precedence — Mounts

Cloud storage via Turbo Drive

Use structured mounts to expose provider-backed cloud folders from Turbo Drive into application containers. Turbo Drive appears as a virtual drive or mount point on the endpoint (for example, T: on Windows, ~/Library/CloudStorage/Turbo Drive on macOS, or /mnt/tdrive on Linux) and aggregates provider namespaces (OneDrive, Dropbox, SMB). This avoids relying on local sync clients or UNC/NFS/SMB paths and enables tight policy control.

Key points

• Source paths point to Turbo Drive namespaces. Common patterns:
  • Windows: T:\\OneDrive\\..., T:\\Dropbox\\..., T:\\SMB\\...
  • macOS: ~/Library/CloudStorage/Turbo Drive/OneDrive/..., ~/Library/CloudStorage/Turbo Drive/Dropbox/..., ~/Library/CloudStorage/Turbo Drive/SMB/...
  • Linux: /mnt/tdrive/OneDrive/..., /mnt/tdrive/Dropbox/..., /mnt/tdrive/SMB/...
• Destinations use stable container paths (tokens like @DOCUMENTS@).
• Scope mounts globally, per app, or per launch profile.
• Use options to choose read-write or read-only.
• Gate with ABAC via visibility.abac.requirements.

Examples

Global OneDrive Documents (read-write)

{
  "configuration": {
    "launch": {
      "mounts": [
        {
          "name": "OneDriveDocs",
          "source": "<TDRIVE_ONEDRIVE_USER_DOCS>",
          "destination": "@DOCUMENTS@\\Cloud\\OneDrive",
          "options": ["read-write"]
        }
      ]
    }
  }
}

Use the appropriate Turbo Drive path for <TDRIVE_ONEDRIVE_USER_DOCS> on each platform (for example, T:\\OneDrive\\... on Windows, ~/Library/CloudStorage/Turbo Drive/OneDrive/... on macOS, /mnt/tdrive/OneDrive/... on Linux).

Per-app Dropbox Team folder (read-only)

{
  "apps": [
    {
      "id": "adobe-reader",
      "modifications": {
        "mounts": [
          {
            "name": "DropboxTeam",
            "source": "<TDRIVE_DROPBOX_TEAM_FOLDER>",
            "destination": "@DOCUMENTS@\\Cloud\\DropboxTeam",
            "options": ["read-only"]
          }
        ]
      }
    }
  ]
}

Profile-scoped SMB share for editors (read-write)

{
  "apps": [
    {
      "id": "contoso-doc-editor",
      "profiles": [
        {
          "id": "editor",
          "label": "Editor Mode",
          "mounts": [
            {
              "name": "DeptShare",
              "source": "<TDRIVE_SMB_DEPT_SHARE>",
              "destination": "@DOCUMENTS@\\Cloud\\DeptDocs",
              "options": ["read-write"],
              "visibility": {
                "abac": {
                  "requirements": { "userAttributes": { "role": "editor" } }
                }
              }
            }
          ]
        }
      ]
    }
  ]
}

For full provider-specific patterns and platform tables (OneDrive, Dropbox, SMB), see Cloud Storage Integration.

Notes

• Do not configure cloud folders (including Turbo Drive namespaces) as Files tab Storage Contexts. Storage Contexts are reserved for local Secure Sandbox storage volumes. Use Turbo Drive mounts for cloud.
• See provider setup and details: Cloud Storage Integration.

Configuration templates and user configurations (validation)

Enterprise configuration templates can constrain user‑provided mounts (sources, destinations, options). End users define per-user configurations (workspaces) that reference these templates; supplied mounts are validated against the enterprise allowlists.

• Templates (enterprise constraints): Configuration Templates
• User configurations (per-user workspaces): User Configurations
• Schema reference: Policy Schema, User Configurations Schema

Validation highlights:

• source must match allowedSourcePatterns
• destination must match allowedDestinationPatterns
• options must be within allowedOptions
• Environment variables and tokens resolve at validation time

Troubleshooting quick checks

• Files tab error:
  • Ensure configuration.launch.runtime.files.contexts defines at least one valid Storage Context.
• Structured mounts not appearing / conflicting:
  • Verify scope precedence and merging rules.
• Validation failures with user configurations:
  • Confirm requested paths/options match template allowlists.