Forum Discussion

frithjof_v's avatar
frithjof_v
Icon for Community Champion rankCommunity Champion
2 years ago
Solved

Notebook - mount a lakehouse fails

I'm trying to mount a lakehouse from another workspace to my Notebook by using this code:   notebookutils.fs.mount( "abfss://<workspace_id>@msit-onelake.dfs.fabric.microsoft.com/<lakehouse_id>",...
notebook
  • Anonymous's avatar
    Anonymous
    2 years ago

    Hi frithjof_v ,

     

    I failed at first with this code because the default timeout may not be enough, after increasing the timeout I succeeded:

    notebookutils.fs.mount (
    “abfss://<workspace_id>@msit-onelake.dfs.fabric.microsoft.com/<lakehouse_id>”,
    “/test”.
    {“timeout”: 600} 
)

     

    If you have any other questions please feel free to contact me.

     

    Best Regards,
    Yang
    Community Support Team

     

    If there is any post helps, then please consider Accept it as the 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!

Anonymous's avatar
Anonymous
Not applicable
2 years ago

Hi frithjof_v ,

Could you please mark this helpful post as “Answered”?

 

This will help others in the community to easily find a solution if they are experiencing the same problem as you.

 

Thank you for your cooperation!

 

Best Regards,
Yang
Community Support Team

 

If there is any post helps, then please consider Accept it as the 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!

dbeavon3's avatar
dbeavon3
Icon for Memorable Member rankMemorable Member
1 year ago

Hi Anonymous 

These failures are happening in our default LH mounts, even before our notebook cells start executing.  Is this the same bug?

 


Have you reported this bug to the PG yet?  Is there an ICM number that you can share?  If you cannot share that identifier here, can you please add the details to the internal notes on my SR:
TrackingID#2501220040016849

This needs to be added to the "known issues" list, if customers are expected to use workarounds to avoid these bugs in their default mounts.

Customers should not be forced to make sure that the (default) mount is successful by executing this command to list all the mount points. mssparkutils.fs.mounts(). 

... It would be far better if the PG would crash the notebook right at the start, as opposed to allowing the notebook to begin execution with an invalid session/environment.  No Fabric customer wants to deal with an invalid session;  and we don't want to experience random and unpredictable errors in our code, as a result of a software bug from Microsoft.   The experience is very confusing to a pyspark-notebook-developer, and is even more confusing when a developer must explain to their users why their workloads are dying.  These end-users are NOT likely to believe us (an average pyspark-notebook-developer)  when we blame the Microsoft Fabric platform for our unreliable workloads.  Hopefully this makes sense.  (... yet it has been months since you shared your workaround and there is still no relief from the PG, and nothing appears in the "known issues" list.)