Failed to convert to managed table: PrivilegedGenerateTemporaryTableCredential disable

[Davide]

Hello everyone, 

I noticed that when I tried to convert some external table to managed one using the alter table catalog.schema.table_name set managed command (like suggested by databricks) sometimes I will encounter this error: 

Error running query: com.databricks.sql.managedcatalog.UnityCatalogServiceException: [RequestId=xxxx ErrorClass=FEATURE_DISABLED] Global UC is disabled for PrivilegedGenerateTemporaryTableCredential.

But what's strage is that if then I retry the very same command, on the same table, without restarting the cluster on anything it will succeed. FYI I need to use a serverless cluster for running this command for a series of company reason. I have looked into the documentation and could not find anything. Can someone help me out? thank a lot in advance. 

[data_pulse]

@Davide 

Since the exact same cmd ALTER TABLE .. SET MANAGED succeeds immediately on retry, It doesn't seem like Serverless specific issue. The error is being raised by Unity Catalog during a temporary table credential operation and PrivilegedGenerateTemporaryTableCredential does not appear to be documented as a user-configurable feature.

SET MANAGED is supported on Serverless and Databricks documents retrying interrupted conversions. If this happens intermittently across multiple tables, raising the issue with databricks support makes more sense.

[balajij8]

@Davide 

The command generates temporary table credentials to access the cloud storage backing the external table. Its generally the same mechanism Unity Catalog uses for external system access. It indicates that the Unity Catalog control plane transiently declined to issue those credentials for that specific request. Since an immediate retry on the same serverless compute succeeds, it confirms this is a transient race condition in the service and not a misconfiguration.

You can mitigate it by implementing a retry wrapper for the commands, capturing the specific error and attempting again up to a few times with a short backoff. You can also reduce the likelihood of hitting this transient bottleneck by avoiding concurrent conversions and processing the tables sequentially.

You can confirm the standard prerequisites are strictly met at execution time - you own the table, run on Serverless or Runtime 17.3 LTS+ and ensure no background OPTIMIZE jobs are hitting the table during the conversion. You can also open a Databricks support ticket.

[ThomazNeto]

Hi Davide,

The conversion is designed to be resumable. It copies data and the Delta log to the managed location first, then switches the metadata, and the page says plainly that if the command fails you can retry it and it "resumes from where it left off". So a retry that succeeds isn't luck, it's the expected recovery path. That matches what you're seeing.
https://docs.databricks.com/aws/en/tables/convert-to-managed

Three things from the same page worth respecting while you run this:

- Always retry on the same runtime. Since you're on serverless that's covered, but if someone reruns a failed table from a classic cluster you can hit VERSIONED_CLONE_INTERNAL_ERROR because the metadata is serialized differently across versions.
- Don't run two SET MANAGED on the same table at the same time, the docs warn it can leave the table in an inconsistent state. Sequential per table is the safe pattern.
- Cancel any OPTIMIZE / liquid clustering / ZORDER jobs on those tables and don't schedule any during the conversion.

After a retry succeeds, confirm with DESCRIBE EXTENDED that the table is MANAGED and remember the old files stay in the external location for 14 days for rollback (UNSET MANAGED) and are only cleaned by predictive optimization or a manual VACUUM after that.

The error you pasted carries a RequestId. That plus the timestamp is exactly what Databricks support needs to see what the control plane declined on the first attempt, so if this keeps happening across tables it's worth a ticket. Until then, a simple retry loop with a short backoff is a reasonable way to keep the migration moving.

Hope this helps