OttoFMS OData calls inside the same docker image as FMS

OttoFMS
1

This is a heads-up for anyone running FileMaker Server on Linux in Docker and experimenting with OttoFMS / MCP.

We run FileMaker Server inside a Docker container and installed OttoFMS in the same container. During setup, OttoFMS failed to list scripts when configuring MCP Tools. The browser console eventually showed timeout error when calling the OData proxy endpoint, for example /otto/fmi/data/vLatest/.../scripts

Admin API calls worked, but OData calls consistently timed out from inside the container, which made this tricky to diagnose.

Root cause (Docker DNS):
Inside the container, OttoFMS was calling FileMaker Server using the public hostname (the one matching the TLS certificate). That hostname resolved via normal DNS to the external host address instead of the local container, causing the connection to go out and back in through networking layers and eventually time out.

Fix:
Override DNS resolution inside the container so the public hostname resolves to loopback:

extra_hosts:
    - "fms.hostname.domain:127.0.0.1"

The container must be recreated, not just restarted, for this to take effect.

After this change, OttoFMS can call https://fms.hostname.domain/... internally, the certificate hostname matches, and OData proxy calls (including script listing) work reliably.

One open question: I still do not fully understand why this only affected OData calls and not other FMS communication paths, but the DNS override resolved the issue consistently.

2

Hey Johan,

Due to some issues with improperly formatted container data URLs in the FileMaker Data API and OData when using localhost or 127.0.0.1, OttoFMS calls out to the domain used to make the request to the proxy when calling the Data API or OData. If your server is unable to resolve its own hostname, you can override this behavior by setting the PREVENT_DAPI_CALLOUT environment variable. This will cause the proxies to call directly to OData or the Data API on 127.0.0.1 and their respective ports.

-Kyle

3

Thanks Kyle!

Not sure I understand fully, but wouldn’t it me problematic for TLS validation to use 127.0.0.1 in the communication from OttoFMS to FMS?

4

It shouldn’t be problematic no. If you are attempting to use the container data URLs returned by the Data API I would verify that the URLs are correct or you may need to do some manual remediation of the URLs. In our experience, using direct connection to 127.0.0.1 will result in container data urls with a url of https://undefined/rest/of/url instead of https://server.domain.name/rest/of/url. If that doesn’t matter for you then there’s no reason to go through the hostname again and you can turn on the env variable to avoid the issue entirely (and OttoFMS will call directly to the ports instead of port 443, reducing load on the web server slightly).

-Kyle