Forum Discussion
Error when getting the workspace name from a notebook
I'm just trying to get the workspace name from a workbook with notebookutils and it is choking and dying.
This error happens when running the notebook as a service principal.
this_workspace_name = notebookutils.mssparkutils.env.getWorkspaceName()
... Results in:
Py4JJavaError: An error occurred while calling z:mssparkutils.env.getWorkspaceName.
: org.apache.http.client.HttpResponseException: status code: 403
org.apache.http.client.HttpResponseException: status code: 403, reason phrase: Non HTTP 200 response code. StatusCode=403 Reason=Forbidden
10 Replies
Hi dbeavon3 ,
You can use this, to retrive current workspace name.notebookutils.runtime.context.currentWorkspaceName()Ref : https://learn.microsoft.com/en-us/fabric/data-engineering/notebook-utilities#runtime-utilities
That is helpful. I'll test. I'm assuming it works in both python notebooks and pyspark?
Hi dbeavon3 , Thank you for reaching out to the Microsoft Community Forum.
This is happening because notebookutils.mssparkutils.env.getWorkspaceName() makes an internal API call to fetch workspace metadata, which service principals can’t access by default. In Microsoft Fabric, service principals don’t have implicit rights to read workspace context, this includes the workspace name, even if they have access to the Lakehouse or notebooks.
To resolve it, go to the Fabric workspace and assign the service principal a Contributor or Admin role at the workspace level via the access control settings. This gives it the necessary control plane permissions to access metadata APIs used by that utility function.
If updating permissions isn’t an option, inject the workspace name into the notebook manually using a parameter or environment variable. This avoids the API call entirely and works reliably in service principal contexts.
Hi v-hashadapu
Do you have a reference/link with that information? Is there a known issue? Is it by design? I don't think it is true that service principals are restricted, as compared to normal users. It has not been my experience.
FYI, The service principals are already full admins.
This may be a bug. I found some other related discussions on another forum, but it was quite old (maybe a year?) Is it possible that this sort of bug would remain unfixed for another year? If so, I think Microsoft should provide some documentation about this bug in the meantime. Perhaps they should use their "known issues" list.Hi dbeavon3 , We apologize for the inconvenience. This issue has been documented among the known issues as of April 2025. Our support team is actively working to resolve it as quickly as possible. If you have any additional questions, please feel free to open a new thread in the community. We are here to assist you.
Thank you for your co-operation.
Hi dbeavon3 , hope you are doing well. may i know if the information provided here solved your issue or if you have raised the support ticket as suggested? If your issue's solved either way, please share the insights here, so others with similar issues may find the solution easily.
Thank you.
