Set up access control for folders and tables

Picture this: you've just built a beautiful Lakehouse with curated tables, dashboards, and notebooks. Then a new analyst joins your team and — without thinking — drops a production table, or reads PII data they shouldn't see. Access control in Databricks isn't just about locking things down; it's the invisible safety net that lets your team move fast without breaking things. In this lesson, you'll learn how to set up access control for folders and tables, from the basic concepts to hands-on implementation, so your data stays secure and your workflows stay smooth.

The Problem: Why Uncontrolled Access Breaks Your Lakehouse

Without proper access control, your Databricks workspace is a free-for-all. Anyone with a Contributor role can list every folder, read every table, and even drop or overwrite them. This leads to:

• Data breaches: Sensitive columns like email or ssn become visible to anyone.
• Accidental destruction: A stray DROP TABLE or DELETE FROM wipes out hours of work.
• Compliance failures: Regulations like GDPR and HIPAA require least-privilege access.
• Siloed chaos: Teams struggle to find data because permissions are inconsistent.

The cost of ignoring access control is huge — not just in dollars, but in lost trust. When you can't trust who sees what, you can't trust your data at all.

Core Concept: The Mental Model of Hierarchical Permissions

Think of access control like a building's security system. The workspace root is the front door. Folders are floors, and tables are rooms. You give people badges (permissions) to enter specific areas — not all areas.

Databricks uses a hierarchical permission model:

• Workspace-level roles (e.g., Admin, User) control who can access the entire workspace.
• Folder-level permissions control who can view, edit, or manage notebooks and files inside.
• Table-level permissions (via Unity Catalog or legacy Hive metastore ACLs) control who can SELECT, MODIFY, or OWN specific tables.

Permissions are inherited from parent to child. If you grant READ on a folder, all subfolders and notebooks inherit it — unless you override with a more restrictive rule.

Pro tip: Always use the principle of least privilege. Grant the minimum permissions someone needs to do their job, then expand only when necessary.

How It Works: Step-by-Step Permission Flow

Setting up access control involves three layers. Here's how they interact:

1. Set Workspace-Level Permissions

First, ensure your workspace uses Unity Catalog (recommended) or legacy table ACLs. In the admin console, you can set default permissions for all users.

2. Manage Folder Permissions

In the Workspace sidebar, right-click a folder, go to Permissions, and add users or groups with roles: READ, RUN, EDIT, MANAGE, or OWNER.

3. Manage Table Permissions

Tables are governed by Unity Catalog (if enabled) or Hive metastore. You can grant SELECT, MODIFY, or OWNERSHIP via SQL or the UI.

Permissions are evaluated top-down: workspace → folder → table. If a user has READ on a folder but MODIFY on a table inside it, they can modify that table — but not others.

Hands-On Walkthrough: Lock Down a Project Folder and Tables

Let's apply what we've learned with a concrete example. We'll create a group, set folder permissions, then grant table-level access.

Step 1: Create a Group in Admin Console

In the Admin Console → Groups, create a group called data_analysts and add your users. Groups are easier to manage than individual users.

Step 2: Set Folder Permissions via UI

Go to Workspace → right-click your analytics folder → Permissions → Add Permissions → choose data_analysts → assign READ and RUN. Click Add.

Now your analysts can view and run notebooks, but cannot edit them.

Step 3: Grant Table Permissions with SQL

In a notebook, run the following to grant SELECT on a table to the group:

-- Grant read access on a specific table to the group
GRANT SELECT ON TABLE sales.raw_events TO GROUP `data_analysts`;

-- Verify the grant
SHOW GRANTS ON TABLE sales.raw_events;

Expected output:

Principal         ActionType  ObjectType  ObjectKey         Grantor
----------------  ----------  ----------  ----------------  -------
`data_analysts`   SELECT      TABLE       sales.raw_events  admin

Step 4: Revoke Access When Needed

If someone leaves the team, remove them from the group — or revoke directly:

REVOKE SELECT ON TABLE sales.raw_events FROM GROUP `data_analysts`;

Pro tip: Always use groups instead of individual users. It makes lifecycle management a breeze.

Compare Options: Unity Catalog vs. Legacy Table ACLs

If you're starting fresh, always choose Unity Catalog. If you're on a legacy setup, plan a migration path.

Troubleshooting & Edge Cases

"I granted SELECT but the user still can't see the table"

• Check if the user has READ on the folder containing the notebook that queries the table. Table access isn't enough if the notebook itself is inaccessible.
• Verify the table is in the same catalog and schema — cross-catalog access may require additional grants.

"Permissions don't seem to apply immediately"

• Wait a few seconds; Databricks caches permissions. If in doubt, REFRESH TABLE or re-run the query.

"I see duplicate or confusing grants"

• Use SHOW GRANTS to audit. If both a group and a user have permissions, effective access is the union of both.

"I accidentally locked myself out"

• As an admin, you can always intervene. In the UI, an admin can take ownership of a folder or table via Permissions dialog.

What You Learned & What's Next

You now understand how to set up access control for folders and tables in Databricks. You can explain the hierarchical permission model, apply folder and table permissions, and compare Unity Catalog versus legacy ACLs. You've completed a hands-on walkthrough that grants and revokes access using SQL.

Next up: Dive into Delta Lake time travel — how to query historical snapshots of your tables, which is a powerful complement to access control for auditing and recovery.

Keep your data secure, and your analysts productive!