Power BI Gateway Error: Fix Every Variant (2026 Guide)
Six different gateway error messages, six different actual causes. Most guides tell you to “check the gateway is running” — here’s what to check when it already is.
The Direct Answer
A Power BI gateway error can mean six genuinely different things, and the fix depends entirely on which one you’re seeing. DM_GWPipeline_UnknownError is almost always blocked outbound port 443 traffic to Azure’s relay. “There is no gateway to access the data source” means the dataset is pointed at the wrong gateway cluster. “Could not connect… make sure your file system is active” means the Windows gateway service itself has stopped. DMTS_UpdateClusterDatasourceCredentialsErrorCode means stored credentials no longer match the source. “We could not register this data source” means no cluster member has the right driver installed. “Failed to use the selected gateway” during scheduling usually means the account setting up the refresh was never added as a gateway user.
Diagnose Your Exact Gateway Error
Pick the message you’re actually seeing — the fix is different for each one.
Your specific fix steps will appear here once you select an error above.
Power BI Gateway Error: Why “It’s Online” Isn’t the Whole Story
The admin portal showing a green “Online” status only confirms one thing: the gateway service is running and can reach Microsoft’s cloud. It says nothing about whether the specific data source is correctly registered, whether your account has been granted access to that gateway, or whether the stored credentials are still valid.
That gap — between “the gateway is online” and “this specific refresh actually works” — is where almost every one of these six errors lives. Treat them as separate problems, because the fix for one does nothing for the others.
Service Cannot Reach the Gateway / DM_GWPipeline_UnknownError
What’s actually happening
This means the gateway machine itself can’t establish outbound connectivity to Microsoft’s Azure Service Bus relay — the channel the cloud service uses to reach your on-premises gateway. This is a network problem, not a Power BI problem.
- A corporate firewall or proxy is blocking or inspecting outbound port 443 traffic to the Azure Relay endpoints. This is the most commonly reported cause — whitelist the required endpoints rather than opening the port broadly.
- Antivirus or endpoint protection software is intercepting the connection, particularly SSL-inspection features that break the TLS handshake. Temporarily disabling it to test is the fastest way to confirm this.
- The gateway machine’s system clock is out of sync. TLS handshakes fail if the clock drifts too far, and this is an easy one to overlook since nothing else on the machine appears broken.
“There Is No Gateway to Access the Data Source”
What’s actually happening
This one is misleading because it usually appears even when a gateway genuinely is online and working. The real problem is almost always that the dataset is bound to a different gateway cluster than the one you’re currently looking at — commonly after a workspace migration, or when your organization has multiple gateway clusters with similarly-named or duplicate data sources registered.
- Open the dataset’s gateway connection settings and explicitly remove the existing gateway mapping, then re-add it — don’t assume it carried over correctly from a previous workspace or migration.
- Check whether your organization has more than one gateway cluster with a data source of the same or similar name, and confirm you’re mapping to the correct one.
- If the report/app layer shows this error but the dataset itself refreshes fine, republishing the report often clears it — this is a known workaround, even though it’s treating the symptom rather than the cause.
“Could Not Connect to Your Data Gateway”
What’s actually happening
Despite the confusing “file system” wording, this means the On-premises data gateway Windows service on the host machine has actually stopped — either it was paused, the host machine went to sleep, or it restarted without the service configured to auto-start.
- On the gateway host machine, open
services.mscand confirm the “On-premises data gateway service” is running. - Set that service’s startup type to Automatic so it survives a reboot — this is the single most common preventable cause of this error recurring.
- Check the host machine’s power settings — gateway machines should never be allowed to sleep, since a scheduled refresh can’t wake it back up.
DMTS_UpdateClusterDatasourceCredentialsErrorCode
What’s actually happening
This is a credentials problem, specifically: whatever username and password are stored in the gateway for this data source no longer match what the source system will actually accept.
- Go to Manage Gateway → Data Source Settings and re-enter the credentials directly, then run the connection test from there rather than assuming a previous save is still valid.
- Check whether the service account tied to those credentials has hit a password expiry policy — this is an extremely common trigger, especially for accounts governed by standard corporate rotation policies.
- Confirm the account still has the required permissions on the source system itself — a credentials change on the source side (revoked access, role change) produces this same error.
“We Could Not Register This Data Source for Any Gateway Instances”
What’s actually happening
This shows up when adding a new data source, and it means none of the machines in your gateway cluster currently have what’s needed to connect to that specific source type — usually a missing provider or driver, not a permissions issue.
- Confirm the required driver (for example, the correct OLE DB or ODBC provider for that source type) is installed on every machine in the cluster, not just the one you tested on.
- Check that at least one cluster member is actually online — a cluster can show “healthy” overall while individual members are down.
- Confirm the gateway version itself supports that data source type; older gateway installations sometimes lack newer connectors entirely.
“Failed to Use the Selected Gateway”
What’s actually happening
This typically appears while setting up a scheduled refresh, and despite what it says, it’s rarely actually about the gateway being down. The more common cause is that the account trying to configure the schedule was never added as a user on that gateway — installing a gateway doesn’t automatically share it with your whole team.
- Have the gateway admin check Manage Gateway → Users and confirm your account is explicitly listed, not just the person who originally installed it.
- If you are listed, confirm your permission level actually allows configuring data source connections, not just viewing status.
- Only after confirming user access, treat it as an actual availability issue and check the gateway’s online status.
The General Troubleshooting Order That Actually Works
Microsoft’s own gateway troubleshooting documentation is worth reading alongside this guide for edge cases outside the six variants covered here, particularly around gateway cluster architecture and Azure Relay connectivity specifics.
✅ Work Through It In This Order
- Check the gateway’s actual status in the admin portal — not just “installed,” confirm it shows Online right now.
- Test the specific data source connection from within Manage Gateway, separately from checking overall gateway status — these are two different things.
- Check Windows Services on the host machine if the gateway shows offline or intermittent — this rules out the service having simply stopped.
- Check outbound firewall rules for port 443 to the required Azure endpoints if the gateway can’t reach the cloud at all.
- Re-test credentials directly against the source, separate from testing them through the gateway.
- Check gateway user permissions for the specific account trying to configure or run the refresh — this is the step people skip most often.
⚠️ Don’t reinstall the gateway as your first move. It occasionally “fixes” things by accident, the same way restarting a computer does — but if the underlying cause is a firewall rule, an expired credential, or a missing user permission, a fresh install hits the exact same wall within days.
Quick Reference Table
| Error | Most Common Cause | First Thing to Check |
|---|---|---|
DM_GWPipeline_UnknownError | Blocked outbound port 443 to Azure Relay | Firewall/proxy whitelist rules |
| No gateway to access data source | Dataset bound to wrong gateway cluster | Remove and re-add gateway mapping |
| File system / not active | Windows gateway service stopped | services.msc on host machine |
DMTS_UpdateClusterDatasourceCredentialsErrorCode | Stored credentials no longer valid | Re-test credentials in Manage Gateway |
| Could not register data source | Missing driver on cluster member(s) | Confirm driver on every cluster machine |
| Failed to use selected gateway | Account not added as gateway user | Manage Gateway → Users tab |
Frequently Asked Questions
What causes DM_GWPipeline_UnknownError or “The service cannot reach the gateway”?
Why does Power BI say “There is no gateway to access the data source” when the gateway is online?
What does “Could not connect to your data gateway. Make sure your file system is active” mean?
What is DMTS_UpdateClusterDatasourceCredentialsErrorCode?
Why can’t I register a new data source on my gateway cluster?
How do I fix “Failed to use the selected gateway” when scheduling a refresh?
How This Guide Was Built
Root causes and fixes are drawn from Microsoft’s own official gateway troubleshooting documentation, cross-referenced against real, dated threads on the Microsoft Fabric Community forum spanning 2016 through 2026, where administrators diagnosed and resolved each specific variant. Fixes are ranked by how frequently they’re reported to resolve the issue, not by which is simplest to explain.
Written and verified by A.J., Data Engineering Researcher · Ultimate Info Guide
