Databricks Mount and Unmount Data Lake: DBFS vs Unity Catalog

Databricks DBFS mounts are now a legacy approach. If you are setting up a new Databricks workspace, Databricks recommends using Unity Catalog external locations or volumes to access Azure Data Lake Storage (ADLS Gen2) instead of mounting storage under /mnt. DBFS mounts are deprecated and are not available in new Databricks accounts.

Quick answer: For new Databricks implementations, use Unity Catalog. Use an external location when you need governed access to an existing ADLS Gen2 path, or a Unity Catalog volume when working with files. The dbutils.fs.mount() approach shown later is retained for legacy environments that still use DBFS mounts.

Databricks Mount vs Unity Catalog

Access Azure Data Lake Storage with Unity Catalog

For an ADLS Gen2 container, the current Databricks approach is to create a storage credential and then an external location. The storage credential defines the identity used to access Azure storage, while the external location defines the ADLS path and associates it with that credential.

For example, an ADLS Gen2 path uses the following format:

abfss://<container>@<storage-account>.dfs.core.windows.net/<path>

1. Create a storage credential

In Azure Databricks, create a Unity Catalog storage credential that uses an Azure managed identity or supported service principal to access the ADLS Gen2 storage account. The identity needs the appropriate Azure Storage permissions for the data it will access.

2. Create an external location

You can create the external location from Catalog Explorer or with SQL. The SQL pattern is:

CREATE EXTERNAL LOCATION [IF NOT EXISTS] <location-name>
URL 'abfss://<container>@<storage-account>.dfs.core.windows.net/<path>'
WITH (STORAGE CREDENTIAL <storage-credential-name>);

After creating the external location, grant the required Unity Catalog privileges to the users, groups, or service principals that need access.

3. Access files through a Unity Catalog volume

If the requirement is to work with files rather than tables, a Unity Catalog volume can provide a governed file path such as:

/Volumes/<catalog>/<schema>/<volume>/<path-to-file>

External volumes can use existing cloud storage paths governed by Unity Catalog. This is generally a better fit than creating a DBFS mount for file-based workloads.

Important: Unity Catalog provides centralized governance and permissions for these objects. Avoid embedding storage account keys or other long-lived credentials directly in notebooks when a Unity Catalog storage credential can be used instead.

Legacy: How to Mount and Unmount Data Lake in Databricks

The following section documents the older DBFS mount method because you may still encounter it in existing Databricks projects. Databricks now considers DBFS mounts deprecated and recommends migrating to Unity Catalog.

Mounting object storage creates a workspace-level alias under /mnt. The older method commonly used dbutils.fs.mount() to connect cloud storage to DBFS.

Legacy prerequisites:
1. An existing Databricks workspace and compute resource.
2. An Azure Storage account with an ADLS Gen2/Blob container.
3. Appropriate credentials for the storage account.
4. An existing environment where DBFS mounts are still supported.

The original example uses these values:

ContainerName = "yourcontainerName"
azure_blobstorage_name = "blobstoragename"
mountpointname = "/mnt/azureops"
secret_key = "xxxxxxxxxxx"

Mount an Azure Storage location

For legacy environments using the WASBS pattern, the mount command looks like this:

dbutils.fs.mount(
    source=f"wasbs://{ContainerName}@{azure_blobstorage_name}.blob.core.windows.net",
    mount_point=mountpointname,
    extra_configs={
        "fs.azure.account.key." + azure_blobstorage_name + ".blob.core.windows.net": secret_key
    }
)

List existing mount points

dbutils.fs.mounts()

Unmount a location

dbutils.fs.unmount("/mnt/azureops")

Should You Still Use Databricks Mounts?

For new workloads, no. Databricks now recommends Unity Catalog volumes, external locations, or workspace files instead of DBFS mounts. DBFS mounts are not compatible with Databricks serverless compute and are not available in newly provisioned accounts.

If you have an existing application that depends on /mnt paths, treat the mount configuration as a legacy dependency and plan a migration to Unity Catalog rather than building new workloads around it.

Key Takeaways

• New Databricks workloads: use Unity Catalog.
• Existing ADLS Gen2 data: use a Unity Catalog external location when you need governed access to an existing storage path.
• File-based workloads: consider Unity Catalog volumes.
• Existing DBFS mounts: they can still appear in older environments, but Databricks recommends migrating away from them.

Microsoft documentation: Connect to ADLS Gen2 using Unity Catalog · DBFS and Unity Catalog best practices · Unity Catalog volume paths

Notebook reference:

Pavan Bangad

9+ years of experience in building data warehouse and big data application.
Helping customers in their digital transformation journey in cloud.
Passionate about data engineering.