Delta Sharing recipient can't see or read shared tables: provider and recipient checks

#Symptoms

• Recipient workspace: SHOW SHARES IN PROVIDER returns nothing, or the catalog created from the share is empty.
• Open-sharing recipient (pandas/Power BI/Spark outside Databricks): 403 / Token expired / invalid bearer token.
• Reads work but streaming or CDF on the shared table fails.
• Some tables in the share fail with a protocol or "unsupported table feature" error.

#First: which kind of recipient is it?

Most problems differ by type, so confirm it:

DESCRIBE RECIPIENT partner_analytics;

#Provider-side checks

1. Is the table in the share, and is the recipient granted?

SHOW ALL IN SHARE sales_share;
SHOW GRANTS ON SHARE sales_share;

Both must be true: the table (or schema) is added to the share and SELECT on the share is granted to the recipient:

ALTER SHARE sales_share ADD TABLE prod.sales.orders;
GRANT SELECT ON SHARE sales_share TO RECIPIENT partner_analytics;

2. Partitions and aliases. If the table was added with a partition filter, the recipient only sees those partitions. With an alias, they see it under the alias name, not the original.

3. Streaming and CDF need history. To let recipients stream from a table or read its change feed, share it with history (and enable CDF on the source table for CDF):

ALTER SHARE sales_share ADD TABLE prod.sales.orders WITH HISTORY;

If the table was added without it, remove and re-add it (recipients lose access briefly), or use ALTER SHARE ... ALTER TABLE where your runtime supports it.

4. Table features. Deletion vectors, column mapping and other table features require a recipient client that supports them. Databricks recipients on current runtimes handle them; older open-source connectors and BI tools may not. Options: upgrade the client, or share a copy of the table without those features.

#Recipient-side checks: Databricks-to-Databricks

SHOW PROVIDERS;
SHOW SHARES IN PROVIDER contoso_provider;
CREATE CATALOG IF NOT EXISTS contoso_sales USING SHARE contoso_provider.sales_share;

• Wrong sharing identifier. The provider must use the recipient metastore's identifier (Catalog Explorer > Delta Sharing > "Shared with me" > copy identifier). A workspace in a different region has a different metastore.
• No catalog created. A share shows under the provider but nobody created a catalog from it; grant permissions on that catalog to users as you would for any catalog.
• Users can't see it. The catalog exists but users lack USE CATALOG / USE SCHEMA / SELECT on it.

#Recipient-side checks: open sharing

Activation link already used. The credential file can be downloaded once. If it was lost, the provider must rotate the token, which creates a new activation link:

databricks recipients rotate-token partner_analytics --existing-token-expire-in-seconds 3600

--existing-token-expire-in-seconds keeps the old token valid briefly so the recipient can switch without an outage.

Token expired. Token lifetime is set at the metastore level. Check DESCRIBE RECIPIENT for expiry, and agree a rotation schedule with the recipient.

IP access list. A provider can restrict the recipient to IP ranges. The recipient's egress IP (often a corporate proxy or a cloud NAT) must be listed.

Test the credential from Python:

import delta_sharing
profile = "/secure/config.share"
client = delta_sharing.SharingClient(profile)
print(client.list_all_tables())
df = delta_sharing.load_as_pandas(f"{profile}#sales_share.sales.orders", limit=10)

If list_all_tables() works but load_as_pandas fails, the issue is the table (features, history, partition filter), not authentication.

#Quick table

#Prevent it next time

• Keep a share register: share, tables, recipient, owner, token expiry date.
• Alert before open-sharing tokens expire, and rotate with an overlap period.
• Test recipient access from the recipient's real client before announcing a share.
• Related: choosing Delta Sharing vs federation.