Forum Discussion
Solved
403 Access denied - OneLake Shortcut + RLS + OneLake Security
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, que...
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
- 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.
- 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.
- 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
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
- 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.
- 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.
- 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