403 Access denied - OneLake Shortcut + RLS + OneLake Security

[mbn_2025]

Hello,

We are testing a Silver → Gold architecture in Microsoft Fabric where Gold reads Silver through OneLake Shortcuts.
As soon as we enable RLS (SQL Endpoint) together with OneLake Security, queries through the shortcut fail.

What we observe:

• Query works directly in Silver

• Query fails in Gold (table is a shortcut)

SQL endpoint error:

• 403 Forbidden

• UnauthorizedToAccessTableFiles

• Access is denied on table … with a OneLake path to a part-xxxxx.snappy.parquet file

Other symptoms:

• Some objects appear under dbo > Unidentified

• Table sync fails with: table change state is Unknown / Resilience check failed

Our tests / checks:

• Lakehouse item permissions: Read all SQL endpoint data

• OneLake Security configured (at least on Tables/)

Question

Based on these tests and the error details above, can you confirm whether this is a known limitation or bug with cross-workspace OneLake Shortcuts when RLS + OneLake Security are enabled?
If so, what is the recommended configuration/architecture to keep RLS while consuming Silver data from Gold via shortcuts?

[mbn_2025]

Hello,

We are testing a Silver → Gold architecture in Microsoft Fabric where Gold reads Silver through OneLake Shortcuts.
As soon as we enable RLS (SQL Endpoint) together with OneLake Security, queries through the shortcut fail.

What we observe:

• Query works directly in Silver

• Query fails in Gold (table is a shortcut)

SQL endpoint error:

• 403 Forbidden

• UnauthorizedToAccessTableFiles

• Access is denied on table … with a OneLake path to a part-xxxxx.snappy.parquet file

Other symptoms:

• Some objects appear under dbo > Unidentified

• Table sync fails with: table change state is Unknown / Resilience check failed

Our tests / checks:

• Lakehouse item permissions: Read all SQL endpoint data

• OneLake Security configured (at least on Tables/)

Question

Based on these tests and the error details above, can you confirm whether this is a known limitation or bug with cross-workspace OneLake Shortcuts when RLS + OneLake Security are enabled?
If so, what is the recommended configuration/architecture to keep RLS while consuming Silver data from Gold via shortcuts?

[ssrithar]

Hi @mbn_2025 ,

At the moment, combining all three (Shortcut + SQL Endpoint RLS + OneLake Security) is not fully supported in cross-workspace scenarios.

Instead of using a shortcut, physically materialize Gold tables using a Dataflow Gen2, Notebook, or Pipeline.
RLS then operates locally and avoids file-level cross-workspace checks.

If this is an enterprise medallion architecture, the recommended long-term pattern is to materialize Gold or centralize RLS in the semantic layer.

If this post helps, then please appreciate giving a Kudos or accepting as a Solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!

[MohdZaid_]

Hey @mbn_2025  ,

What you’re seeing is not a misconfiguration on your side it’s a known limitation in the current Fabric security model when you combine:

True - OneLake Shortcuts (Silver → Gold)
True - SQL Endpoint RLS
True - OneLake Security (file level security)
False - Cross-workspace access

That combination can produce exactly the symptoms you described.

Why this happens

When you query:

• Silver directly → works
• Gold (which points to Silver via shortcut) → fails with
  403 Forbidden – UnauthorizedToAccessTableFiles

What’s happening under the hood:

1. The SQL Endpoint evaluates RLS.
2. The query then resolves the shortcut path.
3. Fabric attempts to read the underlying parquet files in Silver.
4. OneLake Security enforces file-level permissions.
5. The identity used in that context does not have permission on the physical files.
6. Result → 403 UnauthorizedToAccessTableFiles.

The key point:
RLS is enforced at the SQL layer, but OneLake Security is enforced at the storage layer.
With shortcuts, the storage-layer permission check happens against the source lakehouse, not just the consuming (Gold) one.

That’s why:

• You see parquet file path errors
• Tables show under dbo > Unidentified
• Table sync shows Unknown / Resilience check failed

Those are typical signs of storage-layer access being blocked.

Current limitation : Cross-workspace shortcuts + RLS + OneLake Security is not fully aligned yet.

When you enable both:

• RLS (SQL endpoint)
• OneLake Security (file-level restrictions)

Fabric may fail because:

• The security context does not flow correctly across the shortcut boundary.

This is currently considered a platform limitation rather than a supported architecture pattern.

If you need to keep RLS and still move Silver → Gold, here are the safer options:

Option 1 – Avoid OneLake Security on Silver

• Keep: RLS at the SQL endpoint
  Remove: OneLake Security at the file level

Let SQL endpoint handle all access control.

This is the cleanest approach if RLS is your primary security model.

Option 2 – Keep everything in the same workspace

Shortcuts within the same workspace behave more consistently because identity resolution is simpler.

Cross-workspace + layered security increases failure risk.

Option 3 – Physical copy instead of shortcut

Instead of using a shortcut:

• Use a notebook or data pipeline to copy Silver tables into Gold
• Apply RLS only in Gold

This avoids cross-lakehouse file access checks entirely.

Yes, it duplicates storage but it’s the most stable enterprise pattern today.

Option 4 – Use only SQL Endpoint security

If your goal is user-based filtering:

• Remove OneLake Security
• Apply RLS at the Gold SQL endpoint only
• Grant users access only to Gold

This aligns better with how Fabric evaluates security.

If it solved your issue, feel free to mark it as the solution so others can benefit too.

Thanks for being part of the community.

[MJParikh · Accepted solution]

Hi @mbn_2025,

Yes, this is a current limitation of OneLake RLS with OneLake‑to‑OneLake shortcuts queried through a SQL endpoint, not a simple misconfiguration on your side. To keep RLS and still build a Silver → Gold pattern, you need either to point consumers back to the original RLS tables or materialize a Gold copy instead of relying on cross‑workspace shortcuts.​

Why the shortcut query fails

• OneLake RLS enforces security in two ways: either by filtering rows in supported engines, or by blocking access entirely for unsupported paths.​
• The docs state that tables with RLS rules “cannot be read outside of supported Fabric engines,” which triggers an access‑denied behavior instead of returning partial data.​
• In practice, OneLake‑to‑OneLake shortcuts use passthrough auth, where the user identity flows to the source item, and access requires Read / ReadAll permissions on both shortcut path and target path.
• Community reports describe the same pattern you see: non‑RLS tables work through shortcuts, while RLS tables return 403 / UnauthorizedToAccessTableFiles, and Microsoft staff confirm this reflects RLS blocking access on that path.​
• The “table change state is Unknown / Resilience check failed” error appears in other shortcut scenarios when the SQL endpoint cannot validate table metadata from the underlying Delta log, often treated as a platform validation issue rather than table corruption.

So your outcome matches current product behavior when SQL endpoints query RLS‑secured tables through cross‑workspace shortcuts.

What this implies for your design

• With OneLake‑to‑OneLake shortcuts, only passthrough mode is available, and security configuration stays at the source item; downstream items do not redefine access on top of the shortcut.
• Row‑level security in OneLake is documented as a feature of OneLake security that applies to Delta tables and is evaluated per role when users query via supported engines such as Lakehouse SQL endpoints configured for “User’s identity.”​
• Tables with RLS rules are explicitly allowed only for a defined set of engines, and other access paths are treated as blocked rather than partially trusted.​
• The net result: an RLS table read directly in the Silver Lakehouse SQL endpoint works, while the same table read from Gold via a shortcut is treated as an unsupported access path and fails with 403.​​

Recommended patterns to keep RLS

1. Single RLS lakehouse, multiple consumers

• Keep Silver as the single secured lakehouse with OneLake security and RLS defined on the tables.​
• Expose those tables directly from the Silver SQL endpoint and create semantic models in a “reporting” workspace by using shared or certified semantic models instead of shortcuts.​
• Consumers reach Silver logically through models, while your physical storage and security model stay in one place.

1. Materialized Gold, no RLS on shortcuts

• Use Dataflow Gen2, Copy Activity, or pipelines to materialize Gold tables into the Gold Lakehouse instead of pointing Gold to Silver through shortcuts.
• This lets Fabric author the _delta_log in the Gold Lakehouse, which avoids “Resilience check failed / table change state is Unknown” issues linked to external logs.
• Recreate OneLake security roles and RLS on the Gold tables if you need independent row filters for Gold, or keep RLS only in Silver and push aggregated / anonymized Gold tables that no longer require row‑level rules.​

1. Move RLS to the semantic model layer for shortcut‑based Gold

• If shortcuts from Gold to Silver are non‑negotiable, remove OneLake RLS from those Silver tables and instead implement RLS in the Power BI semantic model that reads through the shortcut.​​
• Power BI RLS operates on the semantic model and does not rely on OneLake RLS, so the shortcut path no longer triggers the RLS blocking behavior in OneLake itself.​
• This shifts security responsibility out of OneLake and into the BI layer, which fits scenarios where storage‑level RLS conflicts with cross‑workspace consumption patterns.

If you want to keep experimenting with the current layout:

• Confirm the SQL analytics endpoint for the RLS Lakehouse is set to “User’s identity” as required for OneLake security and RLS.​
• Verify that the same user has at least Read / ReadAll permissions on both the shortcut path in Gold and the target table path in Silver, either via workspace roles or OneLake data access roles.
• Validate that non‑RLS tables work through the same shortcut pattern; this helps you show that only RLS‑protected tables fail, which aligns with known behavior.​

Thank you!

Proud to be a Super User!

📩 Need more help?

✔️ Don’t forget to Accept as Solution if this guidance worked for you.

💛 Your Like motivates me to keep helping