Repository navigation
[BUG] bulk-export errors with "[NotSupported] Only supported for Lakehouse/Files" #287
Description
Bug Description
When attempting to do a bulk export of items from any workspace or folder I get the error
"x bulk-export: [NotSupported] Only supported for Lakehouse/Files"
The error is actually regarding the output filepath parameter
fab bulk-export <workspace>/<folder> -o ./ --recursive
.. fails
fab bulk-export <workspace>/<folder> -o ./temp --recursive
.. succeeds.
fabric-cli version
1.7.0
Python version
Python 3.12.0
Operating System
Windows
CLI Mode
Command line mode
Authentication Method
Interactive browser login
Steps to Reproduce
- Go to a local temporary folder.
- Command
fab bulk-export / -o ./ --recursive
(redacted)
Expected Behavior
Users would reasonably assume the path resolution should work for any valid filesystem path
Actual Behavior
Cli immediately errors with
"x bulk-export: [NotSupported] Only supported for Lakehouse/Files"
Bulk export aborts with no items exported.
Additional Context
No response
Possible Solution
Either the path resolver needs updating to allow os-aware filepath formats, or the docs need to be more explicit about the path requirements
Activity
microsoft-github-policy-service commentedon Sep 11, 2026
Thank you for submitting this issue, Reuben Anderson (@reubster).
A member of the Fabric CLI team will review your submission and provide feedback shortly.
rksharma-owg commentedon Sep 12, 2026
I’d like to work on this. I reproduced the failure in the export-path resolver and bulk-export preconditions on current main (
b7af89b), using Python 3.12 on macOS with a synthetic tenant context and existing local directories; no live Fabric export was run.Both
.and./resolve successfully to the current Fabric context, soget_export_pathnever reaches its local-path fallback and raises the Lakehouse/Files error. An existing./tempdirectory reaches the fallback and succeeds.Would you welcome a bulk-export-specific local-directory fix with regression tests for current-directory paths, invalid destinations, and nonempty-directory confirmation? Since bulk export already requires a local destination, I’d keep shared OneLake path precedence unchanged. If that approach fits, could this issue be marked
help wanted? I’ll wait for team acknowledgment before implementation.