FileMaker Server via Linux Docker

Have your Agent Install FileMaker Server in a Linux Docker Container

There's a better way than trying to work out technical configurations 'manually' . . .

For context, I've installed FileMaker Server hundreds of times on the Windows Server OS, the Apple Mac OS, and even the Windows Client OS. This includes installing into a HyperV container on the Windows Server platform.

The Requirement

Last week I sat down with the goal of installing Claris FileMaker Server via Linux Docker. My usual starting point for this sort of new requirement is to open up a browser window and 'google' search the knowledge required.

The most recent public guidance for installing FileMaker Server in Docker was published by ISO Magazine, over three years ago. The video steps through the painstakingly complicated steps required to 'hack' the installer to work within the Mac OS Docker Container.

This video of instructions predates Claris's own Ubuntu build and Docker install script. And the video doesn't mention any of the failure modes that actually show up when you try to follow these steps, today.

This Claris Support Document was published in August 2022 and last updated in July 2024. My assumption was that even these official steps are out of date, and would fail.

The Agentic Approach

Rather than work my way through these steps – that I knew would fail at some point – I decided to ask my Agent, via the Claude Desktop app, to take over the task of the research and therefore the installation, configuration and most importantly, report back the steps required, with the end goal of building an Agentic Skill for Developer 'Next'.

So 'we' built the installation 'together' – the hard way – a real, start-to-finish install, working through every failure as it happened rather than writing from reference of how FileMaker Server is installed, configuration – followed by server administration, which would traditionally have meant manual steps via the Terminal.

Why the Old Guidance Breaks Down

Claris now ships a native arm64 Ubuntu 24.04 build. No x86 emulation needed on Apple Silicon, which is a genuine improvement. But Claris's own bundled installer script, fms_Docker_Installer.sh, can't run on macOS at all. It calls Linux-only host commands for MacVLAN networking that simply don't exist outside a Linux host, and aborts immediately.

The fix isn't complicated once you know it: build the image from Claris's own Dockerfile directly, and configure the container by hand. But nothing published says this, because nothing published has hit it yet.

Example: The obvious substitute, ubuntu:latest, resolved to Ubuntu 26.04 partway through this build. This FileMaker Server release only supports 22.04 and 24.04. Pin the version explicitly, every time. 'Latest' is not a version, it's a moving target.

The Trap That Actually Costs You Data

As part of my usual post-install process, I check the FileMaker Server Admin Console, and found that the Dashboard was reporting that the drive was 96% full.

Here's the one worth remembering above all the others. FileMaker Server installs via apt directly into the container's own writable layer. Not the image. Not a volume. The container itself.

Which means an ordinary docker rm, run for any reason at all, silently deletes the entire FMS installation. Binaries, systemd units, everything. Your actual databases survive, because they live in named volumes you set up separately. But the software that serves them is just gone, and the first sign of trouble is fmsadmin returning 'command not found.'

The fix is a single habit: docker commit an image immediately after install, and again after every meaningful change. Recovery becomes a container restart from a known-good image instead of a full reinstall against a service your clients are waiting on.

What the Claude Skill Actually Covers

Once the container's running, three more things trip people up in ways that look like broken installs and aren't:

A certificate bug with a clean workaround. Importing an externally-generated key via fmsadmin certificate import --keyfile fails with 'Cannot decrypt the private key file,' regardless of cipher, format, or how carefully the password matches. Verified. It's not your key. The fix is to let FileMaker Server generate its own key via certificate create, sign only the resulting certificate externally, and import without --keyfile at all.

Publishing components disabled by default. WebDirect, OData, and the Data API are all off after a completely successful install. Hitting /fmi/webd gets you a 502, which reads like a broken deployment. It's an unconfigured one.

Startup timing that genuinely varies. Confirmed across two separate restarts on the same container, same configuration: OData came up in three seconds once, and took forty-five the next time. There's no fixed number worth waiting. Poll with retries, and don't trust a single check either direction.

FileMaker Server on Docker Skill Download

As per my other Claude Skills, this Skill is released under CC BY 4.0. Feel free to to use it, fork it, adapt it. Attribute it.

The full Claude Skill, including a symptom-organised troubleshooting reference for every gotcha above, is on CadenceUX GitHub.

You can also grab it directly here: cadenceux-fms-docker-setup-v1.0.skill

The Documentation Discipline

The real gap in this whole exercise wasn't a technical one. It was a documentation one, three times over.

We don't just need to rethink how we approach a technical task like this. We need to rethink how we research it, and how we document it once it's solved, so the next person, including future-us, doesn't repeat the same three-year search through stale results.

Approach. Working through the install with an Agent, in real time, changes what 'documentation' even means. It stops being a write-up after the fact, reconstructed from memory of what worked. It becomes a live record of what actually happened, captured as it happens, including the failures a tidied-up retrospective would quietly leave out.

Research. 'Recent' in a search index is not the same as 'current'. A support document from 2022, an installation video from three years ago, and an AI answer summarising both, can all present as the freshest available guidance while all being wrong in the same way. None of them carried a visible signal saying so.

Documentation. So the fix isn't just writing it down. It's writing it down somewhere that carries its own currency. This is why the install steps became a Skill on GitHub rather than another blog post: a Skill has a version number, a CHANGELOG, and a place for corrections to land, instead of ageing silently the way the Claris Support Document did.

Example: This post is itself a case study. It went through three review passes before publishing, typos, formatting, and this section, and the skill it describes had its own correction before release: a missing developer-confirmation step, caught on review and added to the changelog against the same v1.0, not shipped as a quiet rewrite.

The Process for Keeping Documentation Current

• A version marker on the content itself, stating plainly what it was last verified against.

• A changelog that records each correction against a version number, rather than a silent rewrite of the same page.

• A public, open correction path, issues and pull requests, so the community can flag what's gone stale before the next developer wastes a week finding out the hard way.

None of this is hard. It's just easy to skip when the pressure is to get the thing working and move on. The skill attached to this post is one small proof that the discipline holds: it's on GitHub, it's versioned, and it's already been corrected once in the open, in public, before a single reader downloaded it.

Takeaway

This post is the specific story: one install, one Claude Skill, one set of gotchas, all pinned to a version number so they can be corrected as they age.

The better way wasn't just building the Claude Skill. It was what building it taught me about what I still need to know myself, and what I don't. That's a bigger question than one install guide can carry, so it gets its own post: FileMaker Knowledge Delegation. That's where the actual takeaway sits.

More to come . . .