Tableau Server (RMT) – Issues conecting Tableau Desktop to the Resource Monitoring Tool internal PostgreSQL repository using the shipped .tds files

Part A — Enable remote read-only access on the RMT server

Perform these steps on the RMT Master node. For full reference, see the official documentation: Use the RMT .tds files.

The default install path is C:\Program Files\Tableau\Resource Monitoring Tool\master\. If RMT was installed to a different drive or directory, the PostgreSQL configuration files (postgresql.conf and pg_hba.conf) will be located under that custom path instead.

1. Enable the read-only data access user by running:

   • rmtadmin data-access ReadOnly
   • This creates a readonly user and adds a corresponding entry to pg_hba.conf.

2. Confirm the listen address in postgresql.conf. On current versions of RMT, enabling data access in step 1 is expected to update this setting automatically to listen_addresses = '*', which allows the repository to accept remote connections. Open postgresql.conf and verify the change was applied. If the line is still set to the commented default (#listen_addresses = 'localhost'), uncomment it and set it manually:

   • listen_addresses = '*'
   • In some deployments (for example, when RMT is installed to a non-default location) this value may not update automatically, so it is worth confirming rather than assuming.

3. Open pg_hba.conf and add host rules that allow remote clients to authenticate. In addition to the entry added in step 1, add:

   • host all all 0.0.0.0/0 scram-sha-256
   • host all all ::/0 scram-sha-256

4. Restart the database so the listen address change takes effect:

   • rmtadmin restart --db
   • A configuration reload is not sufficient. The listen_addresses setting is only re-read when the database is restarted.

5. Retrieve the read-only password to use for the connection:

   • rmtadmin get db.readOnlyPassword

To confirm the repository is now accepting remote connections, you can run netstat on the Master and verify PostgreSQL is listening on 0.0.0.0:5555 (and [::]:5555) rather than 127.0.0.1:5555.

Part B — Connect from Tableau Desktop

Open the appropriate shipped .tds file in Tableau Desktop and enter the connection details:

• Server: the RMT Master hostname or IP address
• Port: 5555 (this port is fixed for the RMT repository and cannot be changed)
• Database: tabrmt
• Username: readonly
• Password: the value returned by rmtadmin get db.readOnlyPassword

A note on the Require SSL checkbox: whether or not it is selected, the PostgreSQL driver will still attempt an SSL connection. Toggling this option is therefore not a meaningful step when troubleshooting a failed connection.

Part C — If the connection still fails

If Part A is complete and Tableau Desktop still cannot connect, use the following steps to identify where the connection is breaking down.

1. Confirm the repository is healthy locally. On the RMT Master, connect to the tabrmt database as the readonly user on port 5555 using a local PostgreSQL client (such as psql). If this succeeds, the database and credentials are working correctly, which means the problem lies in the path between your workstation and the server rather than with the repository itself.

2. Run an A/B test to isolate the network path. Install and run Tableau Desktop directly on the RMT server and open the .tds file there, then try the same .tds file from your workstation:

   • If it works on the server but fails from the workstation, the issue is in the network path between the two machines rather than with Tableau, the driver, or the repository configuration.
   • If it fails in both places, revisit Part A (listen address, pg_hba.conf entries, and the database restart).

3. If the failure is isolated to the network path, work with your network and security teams to confirm that nothing along the route between your workstation and the RMT Master is interfering with traffic to port 5555, including the SSL negotiation itself. This is important because a device such as a firewall, proxy, or endpoint-security agent can allow the initial connection to open and still interrupt the session while the secure connection is being established, which produces this same error.

   Keep in mind that a basic reachability test (for example, Test-NetConnection on Windows) only confirms that the initial connection can be opened. It does not confirm that a complete, secure session can be established, so a "port is open" result does not rule out this kind of interference.

   The specific remediation depends on which device in your environment is intervening. As one example, this can be resolved by adding a firewall rule that permits traffic from the workstation to the RMT Master on port 5555, but the correct fix will depend on your particular network configuration.