Unity Catalog Volumes for Non-Table File Management: Managed/External, Permissions, and Operations

Unity Catalog Volumes lets you govern files that cannot be structured as Delta Lake tables — raw CSV/JSON/Parquet files, images, ML model artifacts, configuration files, and so on. You can apply UC permission control, auditing, and lineage to the non-table files that used to be managed via DBFS or direct cloud-storage mounts.

This article walks through an overview of Volumes, the difference between Managed and External, SQL/Python examples for creating and operating them, a comparison with DBFS, the permission model, and the points the exam tends to test.

Volumes Overview

A Volume is an object in the Unity Catalog namespace (Catalog → Schema → Volume) and acts as a container for files. While tables manage structured data as rows and columns, Volumes manage files and directories.

• Path format: /Volumes/<catalog>/<schema>/<volume>/<path>
• Access methods: Spark API / dbutils / SQL / REST API / Unity Catalog UI
• Permission control: READ VOLUME (read) / WRITE VOLUME (write)
• Auditing: every file operation is recorded in the audit log

Managed Volume vs External Volume

CREATE VOLUME Syntax

-- Managed Volume の作成
CREATE VOLUME prod.raw.landing_files
COMMENT 'CSVやJSONの着地ファイルを管理するManaged Volume';

-- External Volume の作成
-- External LocationとStorage Credentialが事前に必要
CREATE EXTERNAL VOLUME prod.raw.external_landing
LOCATION 's3://my-bucket/landing/'
COMMENT '既存S3バケットを参照するExternal Volume';

-- Volume の確認
SHOW VOLUMES IN prod.raw;

-- Volume の詳細
DESCRIBE VOLUME prod.raw.landing_files;

-- Volume の削除
DROP VOLUME prod.raw.landing_files;

File Operations

Files inside a Volume can be operated on via SQL, dbutils, or the Python API.

-- SQL: ファイル一覧の取得
LIST '/Volumes/prod/raw/landing_files/2026/03/';

-- SQL: ファイルのアップロード（ノートブックから）
PUT '/Volumes/prod/raw/landing_files/config.json'
  OVERWRITE;

-- SQL: ファイルの削除
REMOVE '/Volumes/prod/raw/landing_files/old_data.csv';

# Python / dbutils: ファイル一覧
files = dbutils.fs.ls("/Volumes/prod/raw/landing_files/")
for f in files:
    print(f.name, f.size)

# Python: ファイルの読み込み
df = spark.read.csv(
    "/Volumes/prod/raw/landing_files/sales_2026.csv",
    header=True,
    inferSchema=True
)

# Python: ファイルの書き出し
df.write.mode("overwrite").parquet(
    "/Volumes/prod/raw/landing_files/output/"
)

# Python: ファイルのコピー
dbutils.fs.cp(
    "/Volumes/prod/raw/landing_files/config.json",
    "/Volumes/prod/raw/landing_files/backup/config.json"
)

Comparison with DBFS

Volumes Permission Model

Permissions on a Volume are granted at the volume level. You cannot set per-file permissions; READ/WRITE at the volume level is the finest granularity.

-- 読み取り権限の付与
GRANT READ VOLUME ON VOLUME prod.raw.landing_files TO `data-analysts`;

-- 書き込み権限の付与
GRANT WRITE VOLUME ON VOLUME prod.raw.landing_files TO `data-engineers`;

-- Volume作成権限の付与（スキーマレベル）
GRANT CREATE VOLUME ON SCHEMA prod.raw TO `data-engineers`;

-- 権限の確認
SHOW GRANTS ON VOLUME prod.raw.landing_files;

READ VOLUME allows reading and listing files, while WRITE VOLUME allows writing and deleting files. Note that these are independent of the table SELECT permission: reading files via a Volume requires READ VOLUME, and querying a table requires SELECT.

Real-world Use Cases

• Landing zone: receive CSV/JSON files from external systems into a Volume and ingest them with Auto Loader
• ML artifacts: store trained models and scoring result files in a Volume
• Configuration files: centrally manage ETL pipeline parameter files (YAML/JSON)
• Images/PDFs: share unstructured data across teams under UC governance

Points the Exam Tests

• The difference in DROP behavior between Managed Volume and External Volume
• That Volume paths differ from DBFS paths (/Volumes/...)
• The granularity of READ VOLUME and WRITE VOLUME (per volume)
• That External Volume requires an External Location to be created first
• Why Volumes is recommended over DBFS (governance, auditing, cross-workspace access)

Check Your Understanding

Frequently Asked Questions