---
title: "Check a database, MCP or HTTP share"
description: "What the connection test proves, what you can fix yourself, and what support needs."
canonical_url: "https://meingpt.com/en/docs/integrations/vault/operations/service-troubleshooting"
language: en
---

# Check a database, MCP or HTTP share

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. 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 verifies that the role genuinely cannot write. | 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.   |

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 the database certificate and trust chain. 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:

1. the approximate time including the time zone,
2. the affected share's name,
3. 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.