Check a database, MCP or HTTP share
What the connection test proves, what you can fix yourself, and what support needs.
A service share shows three separate checks:
- Registration with MeinGPT: MeinGPT knows about the share.
- Local check: The Outpost machine can reach the local target. This runs only when you request it.
- Reachable from MeinGPT: The share's tunnel is connected.
A registered share can therefore still be unreachable. In the Outpost console, open Shares, find the affected row, and choose Test the connection to check the local target. The Outpost does not poll a production database in the background.
When registration fails
If one service fails to register, other services already registered on the same Outpost stay registered. The affected row and its Status view show whether MeinGPT rejected the registration, was unreachable, or returned an invalid response. A rejection includes the HTTP status. The Outpost automatically retries the failed step.
For Service registration rejected by MeinGPT (403), check the service limit and permissions in MeinGPT. A workspace may run one local service by default, counted across all service types and Outposts; a further one is rejected with 403 until the limit is raised (write to enterprise@meingpt.com). For Service registration rejected by MeinGPT (400), check that service's settings. If MeinGPT is unreachable, check the network connection. If the failure persists, use System → Report a problem. Rejected tunnel access can also appear separately for an already registered service; the local connection test does not resolve that platform failure.
What is actually tested
| Kind | What success proves | What it does not claim |
|---|---|---|
| PostgreSQL, MySQL, Microsoft SQL Server | Login, database and selected access level were verified. For read-only access the Outpost also checks the role's write privileges (for MySQL only privileges granted directly, not those from roles). | That every later SQL query is semantically correct. |
| MCP | The MCP handshake succeeds, the tool list responds, and all released tools are present. | That every later tool call succeeds. |
| HTTP | The configured local endpoint responds to a HEAD request. | That other methods, paths or authentication work. |
| Exchange (EWS) | The server answers at the address, offers the chosen sign-in method and the sign-in succeeds. With a test mailbox: the account may read that mailbox through ApplicationImpersonation. | That every mailbox in the role's scope is readable or that every later call succeeds. |
The HTTP test uses the configured endpoint and sends no request body. It runs only when you choose Test the connection.
The most common results
| Message | What you do |
|---|---|
| Outpost stopped | Use the offered button again. It starts the Outpost and then retries the check. |
| Login rejected | Check the username and password in the connection URL. Use a dedicated database role rather than a personal account. |
| Database missing | Check the database name in the URL. The server itself was already reached. |
| Role lacks permission | Ask the database owner to check that role. Do not grant administrator access as a precaution. |
| Read-only needs a role without write access | Create a dedicated reader role. The Outpost will not silently weaken this check. |
| Host name cannot be resolved | Check DNS on the Outpost machine and the host in the URL. |
| Connection refused | Start the local service and check its port. For PostgreSQL also check which address it listens on. |
| Connection timed out | Check the firewall, VPN and route from the Outpost machine. |
| Secure connection could not be verified | Check that the URL's host name is in the database certificate and that the Outpost machine trusts the certificate or its certificate authority. Restart the Outpost after an import. For SQL Server (self-signed default certificate), see Encryption. Do not disable certificate verification. |
After correcting a local connection failure, Test the connection is enough. You do not need to remove the share unless the configuration itself is invalid and the console explicitly tells you to recreate it.
When you need help
Before restarting, open System → Report a problem. Enter only three things:
- the approximate time including the time zone,
- the affected share's name,
- what you did immediately before the failure.
After your explicit confirmation, the Outpost creates a redacted diagnostics
package, uploads it directly, and shows a reference such as SUP-123456. Give
support only that reference; you do not need to email the ZIP. The package is
stored with the support request until that request is deleted.
Inside the package, services.json contains the kind, registration state, a safe
target summary, and the bounded probe result. Database passwords and connection
URLs are not collected. The bundle does contain log excerpts and can include
file names, paths, or search text; review it under your policy.
If uploading is unavailable or not allowed by your policy, choose Save ZIP only. It is the same redacted package as an offline fallback.
Do not send these to support
Do not send the SQLite database, a complete connection URL, or raw logs. Use “Report a problem” or the redacted diagnostics ZIP as the offline fallback.