Check a database, MCP or HTTP share
What the connection test proves, what you can fix yourself, and what support needs.
A service share has two independent states:
- Registered means meinGPT knows about the share.
- Reachable means this machine can reach its local target.
A registered share can therefore still fail. In the Outpost console open Shares, find the affected row, and choose Test the connection. The test runs only when you ask for it; the Outpost does not poll a production database in the background.
What is actually tested
| Kind | What success proves | What it does not claim |
|---|---|---|
| PostgreSQL | Login, database and selected access level were verified. For read-only access the Outpost also verifies that the role genuinely cannot write. | That every later SQL query is semantically correct. |
| MCP | A process accepts connections on the local TCP port. | That the MCP handshake and every tool work. The test deliberately sends no MCP call. |
| HTTP | A process accepts connections on the local TCP port. | That a particular HTTP path or authentication works. The test deliberately sends no HTTP request. |
That smaller statement is deliberate: an invented HTTP health URL could trigger a real customer operation. The Outpost opens the socket and closes it without sending request data.
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 the database certificate and trust chain. Do not disable certificate verification. |
After a correction, 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.