Snowflake Metadata Sync to Snowflake: Permission Requirements and Initialize Backfill Behavior – DataHub Customer Support Portal

Area: Ingestion Issues

Sub-Area: Snowflake Metadata Sync Automation

Issue

When using the Snowflake Metadata Sync automation to propagate DataHub descriptions (table and column) back to Snowflake, users may encounter two related problems: (1) descriptions edited in DataHub do not appear in Snowflake even after the automation is active and apparently healthy, and (2) clicking the Initialize (backfill) button completes without errors but descriptions that existed in DataHub before the automation was enabled remain absent from Snowflake. The first problem is typically caused by insufficient Snowflake permissions on the target objects or a misconfigured executor. The second problem is a documented product limitation: the Initialize function only backfills tags and glossary terms — it does not backfill descriptions. A code fix was subsequently shipped to add description backfill support to the Initialize path.

Error Messages

insufficient privileges to operate on table: <database>.<schema>.<table_name>
OSError: [Errno 28] No space left on device: '/tmp/datahub/ingest/<exec_id>'
Too many errors have occurred in the past hour; skipping issuing query to Snowflake
All connection attempts failed (integrations service metrics scrape for the automation action URN)
CannotStartContainerError: ResourceInitializationError: ... exec: "dockerize": executable file not found in $PATH (remote executor image mismatch — see Additional Notes)

You Might Be Asking

Why are column descriptions I added in DataHub not appearing in Snowflake even though my automation is running?
Does the Initialize / backfill button sync descriptions, or only tags and terms?
What Snowflake privileges does the DataHub service role need to write comments back to Snowflake?
Why does my automation show "Failed" after Initialize even though some descriptions were written?
Can DataHub write comments to tables that come in through a Snowflake data share?

Solution

Part 1 — Verify Snowflake Permissions

Writing table and column comments in Snowflake requires more than SELECT or USAGE. The role configured in the automation must have MODIFY (or OWNERSHIP) on every target table, plus USAGE on the parent database and schema.

Identify the Snowflake role used by your Snowflake Metadata Sync automation (visible in the automation's connection settings).

Check existing grants on a target table:

SHOW GRANTS ON TABLE <database>.<schema>.<table_name>;

Grant the minimum required privileges:

GRANT USAGE ON DATABASE <database> TO ROLE <automation_role>;
GRANT USAGE ON SCHEMA <database>.<schema> TO ROLE <automation_role>;
GRANT MODIFY ON TABLE <database>.<schema>.<table_name> TO ROLE <automation_role>;

Note that Snowflake does not allow comments to be written on objects sourced from a data share (e.g., tables arriving via SHARE). Descriptions for those objects will remain in DataHub only — this is a Snowflake platform limitation, not a DataHub bug.
After granting permissions, re-run the automation or click Initialize. The Initialize process skips objects that already match and never clears an existing comment, so it is safe to re-run.

Part 2 — Understand the Initialize / Backfill Behavior for Descriptions

Prior to the fix described below, the Initialize button only backfilled tags and glossary terms. DescriptionPropagationAction returned an empty asset list during bootstrap, so Initialize completed in seconds with no descriptions written — and no visible error.

Confirm you are on a version of DataHub Cloud that includes the description-backfill fix (shipped after the limitation was identified — see Additional Notes for version guidance).
Ensure your automation has Table Description Sync and Column Description Sync enabled in the automation configuration.
Click the three-dot menu on the automation and select Initialize.
Monitor the automation status. After completion, the summary will indicate:
- How many table/column comments were written to Snowflake.
- How many already matched (skipped — no change made).
- How many failed due to permission errors (review and grant MODIFY as shown in Part 1, then re-run Initialize).
- How many were skipped because the object is not visible to the configured role.
If Initialize reports Failed but some descriptions were written, check the failure details. Common causes:
- Permission errors on specific tables (grant MODIFY and re-run).
- Objects sourced from Snowflake data shares (unfixable by design — Snowflake restriction).
- Objects that no longer exist in Snowflake or are not visible to the role.

Part 3 — Descriptions Added Before the Automation Was Active

The Snowflake Metadata Sync automation is event-driven for live edits. If descriptions were entered in DataHub before the automation was saved and running, those events have already been consumed and will not be re-emitted automatically.

After the description-backfill fix is deployed, use Initialize to push all existing DataHub descriptions to Snowflake in one operation.
If you are on a version without the fix, the only workaround is to re-save each description in DataHub (make a minor edit and save) to generate a new change event that the running automation will pick up.

Part 4 — Executor Configuration and Error Throttling

Confirm the automation's executor is set to default (runs inside the integrations service) rather than a remote executor pool, unless you have explicitly configured and validated a remote executor for this purpose. Misconfigured remote executors can silently loop through failures without surfacing errors in the UI.
If you suspect the error-throttle limit has been hit (the system drops Snowflake operations after 15 errors per hour to prevent account lockout), stop the automation, wait a few minutes, then restart it. Confirm permissions are correct before restarting so errors do not immediately recur.
Check integration service logs for messages such as:
```
Too many errors have occurred in the past hour; skipping issuing query to Snowflake
```
If present, resolve the underlying permission or connectivity error first, then restart the automation.

Additional Notes

Initialize behavior before the fix: On versions prior to the description-backfill fix, clicking Initialize with only "Descriptions" selected processed zero assets and reported success in approximately 8 seconds — this is a symptom of the no-op bootstrap path, not correct behavior.
Initialize does not overwrite blindly: After the fix, Initialize compares the DataHub description against the existing Snowflake comment. If they already match, the object is skipped. If they differ, the DataHub value takes precedence. Review any objects where the Snowflake comment was replaced to confirm the DataHub text is authoritative.
Data shares: Snowflake enforces a platform-level restriction preventing comment updates on objects sourced from a data share. These objects will always appear as failures in Initialize output. This cannot be resolved through permissions.
Remote executor image compatibility (v1.1.x): DataHub Cloud v1.1.x moved to Chainguard Wolfi-based images, removing the dockerize binary. If your remote executor task definition includes a command override referencing dockerize, update it to remove that reference. The correct startup command for v1.1.x remote executor images is:
```
["/start_datahub_executor.sh"]
```
Alternatively, remove the command override entirely to use the image's built-in default.
UI visibility: There is currently no built-in run-history UI for automations. Automation execution status and logs must be retrieved from the integrations service pod or cloud log storage. Contact DataHub Support if you need assistance retrieving logs.
Documentation clarity: Prior versions of the Snowflake Metadata Sync documentation did not clearly state that Initialize only applied to tags and terms. Updated documentation will reflect the post-fix behavior including description backfill support.