Microsoft Fabric

Register a Microsoft Fabric lakehouse so Eddytor discovers the Delta tables in its Tables/ area. Fabric maps onto the Azure registration call with the OneLake endpoint enabled.

Heads up

OneLake has no data at the workspace root. The base path must start with the item segment in {itemname}.{itemtype} form - EddyHouse.Lakehouse/Tables/, never Tables/.

Before you start

A Fabric workspace and a lakehouse inside it - names exactly as Fabric spells them.
Exactly one credential, preferably a service principal (Entra app: client_id + client_secret + tenant_id, with access to the Fabric workspace); else a SAS token, an access key, or a managed identity (Azure-hosted Eddytor only; add client_id for a user-assigned identity).
storage:configure; attaching the connection to an Eddytor workspace also needs storage_configs:share.

Good to know

Unlike Azure Blob, OneLake has no delegated mode - a Fabric connection always carries its own credential, so no linked cloud account applies.

How Fabric names map onto the connection

Fabric concept	Eddytor field	Value
(fixed)	`account_name`	Always `onelake`
Fabric workspace name	`container`	e.g. `fb-eddytor-ws`
Lakehouse name	`base_path`	`<lakehouse>.Lakehouse/Tables/`
OneLake endpoint	`use_fabric_endpoint`	`true`
(derived)	config name	`{account_name}-{container}`, so `onelake-fb-eddytor-ws`

Register

eddytor create storage azure --account-name onelake --container fb-eddytor-ws \
  --use-fabric-endpoint --base-path "EddyHouse.Lakehouse/Tables/" \
  --client-id "$CLIENT_ID" --client-secret "$CLIENT_SECRET" --tenant-id "$TENANT_ID"
# other auth modes, in place of the service-principal flags:
#   --sas-token … | --access-key … | --use-msi

POST /v1/storages/az
Authorization: Bearer edd_live_…

{ "account_name": "onelake", "container": "fb-eddytor-ws",
  "use_fabric_endpoint": true, "base_path": "EddyHouse.Lakehouse/Tables/",
  "client_id": "…", "client_secret": "…", "tenant_id": "…" }

register_az_storage(account_name="onelake", container="fb-eddytor-ws",
  use_fabric_endpoint=true, base_path="EddyHouse.Lakehouse/Tables/",
  client_id="...", client_secret="...", tenant_id="...")

Connections → Microsoft Fabric, then three steps:

Credentials - pick one auth method, fill in its fields.
Lakehouse - the Fabric workspace name and Lakehouse name; account name and base path are derived.
Options - exclude patterns (__unitystorage is always excluded) and the owning Eddytor workspace, then Connect.

Registration probes OneLake before saving, then discovers tables under the base path (How registration works).

Verify

eddytor get storage

The connection appears as onelake-fb-eddytor-ws with its table count; 0 tables on an empty lakehouse is a success, not a failure.

Gotchas

Heads up

A base path without the item segment fails. Addressing the workspace root returns

Required item type extension is missing in the item name. Expected format {itemname}.{itemtype} e.g. mylakehouse.lakehouse

. Point base_path at <item>.Lakehouse/Tables/ for lakehouse-managed Delta tables, or <item>.Lakehouse/Files/… for a file area.

Pass exactly one auth mode - more than one is rejected.
Managed identity needs Azure-hosted Eddytor; elsewhere the probe fails with managed identity unavailable - not running on Azure infrastructure….
The service principal needs access to the Fabric workspace itself, not just the storage account - otherwise the probe returns authentication failed ….
A wrong workspace or lakehouse name surfaces as storage path or bucket not found …; both are case-sensitive.

Azure Blob · How registration works
Rotate stored credentials · Storage probe failures
Create a table in the connection

Before you start

How Fabric names map onto the connection

Register

Verify

Gotchas

Related

On this page