dbfs directory listing has changed

fehrin1 — Mon, 02 Feb 2026 13:10:02 GMT

Today with

databricks -p FREE fs ls dbfs: -l

i get

DIRECTORY 0 1970-01-01T01:00:00Z Volumes
DIRECTORY 0 1970-01-01T01:00:00Z Workspace
DIRECTORY 0 1970-01-01T01:00:00Z databricks-datasets

But until recently i got significantly more output includeing something like

disableddbfs // or the like

Is this a change in my side or on server (Databricks) side?

Re: dbfs directory listing has changed

Louis_Frolio — Mon, 02 Feb 2026 15:18:37 GMT

Hey @fehrin1 , I did some digging and here is what I found.

Short answer: this is almost certainly a server-side/workspace change, not your local CLI. Your workspace now has DBFS root (and mounts) disabled, which is why the CLI only shows the reserved namespaces: Volumes, Workspace, and databricks-datasets. When DBFS root is turned off, those paths remain visible by design, and anything else under the old DBFS root will fail — often with an error along the lines of “Public DBFS root is disabled.”

What changed and why

Databricks is actively deprecating DBFS root and DBFS mounts and phasing them out. Newer workspaces are provisioned without them by default, and existing ones may have them disabled as part of that rollout. In a workspace where DBFS is disabled, you can still access a few well-defined locations:

dbfs:/Volumes/ for Unity Catalog Volumes (fully governed by UC)
dbfs:/databricks-datasets/ for read-only sample data
Workspace files via file:/Workspace, and in supported runtimes also via dbfs:/Workspace with dbutils

The newer Databricks CLI fs group (v0.205+) is aligned with this model. It expects paths like dbfs:/Volumes/… or dbfs:/…, and it won’t magically resurrect DBFS root if the workspace has disabled it.

How to confirm it’s server-side

A quick sanity check is to try creating a directory under the old DBFS root, for example:

databricks fs mkdir dbfs:/tmp/test

If DBFS is disabled, you’ll get a clear failure indicating the DBFS root is disabled. That’s your confirmation this is a workspace policy, not a local CLI issue. You can also check your CLI version with databricks -v — upgrades may tweak output or defaults, but they don’t remove root directories on their own.

What to use instead

For file storage, the recommended path forward is Unity Catalog Volumes. You can list and manage them cleanly with commands like:

databricks fs ls dbfs:/Volumes////…

For small dev or test artifacts, Workspace files are still a good fit and can be accessed via file:/Workspace/… (and, in supported runtimes, via dbfs:/Workspace for dbutils.fs).

One important gotcha: avoid using direct cloud URIs from the CLI. That’s not supported. If you’re using the CLI or dbutils, stick to Volumes or Workspace files.

A note on the “disableddbfs” paths you might remember

During earlier DBFS disablement rollouts, some environments exposed marker directories or partial DBFS views. Today, the behavior is simpler and stricter: when DBFS root is disabled, you only see the reserved namespaces. Older folders like FileStore, tmp, or any disablement markers simply won’t appear anymore.

Cheers, Louis

Re: dbfs directory listing has changed

fehrin1 — Mon, 02 Feb 2026 15:57:53 GMT

While i got a perfectly sound answer, i want to mention that i probably confused the outputs of databricks fs ls (remote) and df (local).

topic dbfs directory listing has changed in Databricks Free Edition Help

dbfs directory listing has changed

Re: dbfs directory listing has changed

Re: dbfs directory listing has changed