2.2.4. OneLake Settings and Data Access
💡 First Principle: OneLake settings act as the master switches controlling how data can flow into and out of your organization's data lake. Flip the wrong switch, and you might accidentally expose internal data externally—or break all your external integrations. These are tenant-level decisions with organization-wide consequences.
Key OneLake Settings
| Setting | Purpose | Default |
|---|---|---|
| Users can access data via ADLS APIs | Allow Azure Data Lake Storage Gen2 API access | Enabled |
| Users can sync data via OneLake file explorer | Desktop sync client access | Enabled |
| Users can create shortcuts | Allow shortcut creation | Enabled |
| Tenant-level data sharing | Cross-tenant data sharing | Disabled |
⚠️ Exam Trap: Disabling ADLS APIs breaks many external tools. Azure Databricks, external Spark clusters, and many third-party tools rely on ADLS APIs to access OneLake data. Understand the downstream impact before changing this setting.
Connecting from outside Fabric: OneLake exposes the same ADLS Gen2 (DFS) and Blob APIs as Azure Storage, so Azure Storage Explorer, AzCopy, Azure Synapse, Azure Databricks and the ADLS SDKs work by pointing at a OneLake URI—nothing has to be exported or mirrored first:
https://onelake.dfs.fabric.microsoft.com/<workspace>/<item>.<itemtype>/Files/...(for exampleSales.Lakehouse), or the ABFS formabfss://<workspace>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/Tables/...- The account name is always
onelake, and the workspace plays the role of the container - Authentication is Microsoft Entra ID—a user, service principal or managed identity with access to the workspace or item; there are no storage account keys (a OneLake SAS is only a short-lived, user-delegated token signed with a key issued to an Entra identity)
