As I try to run the data migration tool I get an error 64 returned and it returns the help instructions.
The guide doesn't include any more information. It says
* The data migration tool returns zero (0) when it is successful, and returns a non-zero number when there is an error. For the meaning of an error, see the error message that the tool outputs.
Does anyone know anything more about error 64?
Hey, @Malcolm , your post made me curious so I plugged it into Claude AI just for giggles. I assume you probably did something similar, but obviously different LLMs can return different results. On the off chance this is helpful, here's the output:
This is a well-known situation — the Claris docs are genuinely unhelpful here. The answer lies in a standard Unix/POSIX convention that the DMT follows.
Error 64 = EX_USAGE — command line usage error.
In the standard sysexits.h header used on macOS and Linux, exit code 64 is defined as EX_USAGE, meaning a command line usage error. Specifically, EX_USAGE (64) means the command was used incorrectly — e.g., with the wrong number of arguments, a bad flag, or bad syntax in a parameter.
The fact that the tool is also printing the help instructions when it returns 64 is a strong confirming signal: that's exactly what well-behaved CLI tools do when they can't parse the command you gave them — they bail out with a usage error and dump the help text.
What to check:
-src_path and -clone_path are both mandatory. If either is absent or misspelled, you'll get this error.-src-path instead of -src_path) will cause the parser to reject the whole command.-clone_account or -src_account must be paired with their corresponding _pwd argument.The best next step is to look closely at the exact command being run and compare it character-by-character against the documented syntax. If you can share the command they're using, I can help spot the issue. <= End Claude output.
Curious what you've figured out.
Aaannddd, just to be pedantic (or annoying?), here's the ChatGPT output (very similar, but a bit more info and guidance)::
Yeah—this is one of those frustrating gaps in the Claris FileMaker Data Migration Tool docs.
“64” is not a FileMaker-specific error code. It’s coming from the operating system exit code layer, not the tool’s internal error catalog.
On both macOS and Linux, exit code 64 conventionally maps to:
EX_USAGE (command line usage error)
In plain terms:
The tool didn’t like how it was invoked.
In practice with the Data Migration Tool, “error 64” is almost always one of these:
-src vs --src, depending on version)chmod +x)This one is especially common and easy to overlook.
Paths with spaces not properly quoted:
"/path/with spaces/file.fmp12"
Run the command manually in Terminal and:
Example:
./FMDataMigration \
-src "/path/source.fmp12" \
-clone "/path/clone.fmp12" \
-target "/path/output.fmp12"
Then immediately:
echo $?
If you see 64, don’t look for a FileMaker error table entry—it’s basically:
“Something is wrong with how you're calling the tool or what you're pointing it at.”
If you paste the exact command your client is running (with paths anonymized if needed), I can usually pinpoint the issue pretty quickly—this error is very pattern-based. <= End ChatGPT output.
Feel free to ban me from the soup now. 
P.S. Both models (and others) have provided me with invalid/unsupported commands at times, so sometimes need pressing a bit.
You'll get the prize for the best answer.
I forgot to return and update with what I found. In short, the FMDataMigration tool does not run on MacOS Tahoe.
I was working across four different machines. Production server, Development server, home laptop, and work laptop.
The production server is running MacOS running FMS19 and will need to have the FMDataMigration tool downloaded and installed. The development server is Ubuntu and running FMS22. Home laptop is running Ventura. Work laptop is running Tahoe.
I wanted to do the migration tests with the same tool that we'll use on the production server. So I downloaded the FMDataMigration and ran a few simple tests at home. All good. I then tried to do the same thing on the work laptop and got the 64 error. The confusing thing for me was that it returned the help instructions, as I was using that as a simple way to verify that the tool would run.
I took me a long time to realise that I was looking at a shell error. I moved onto the Dev server and it ran without skipping a beat.
I figured you probably had it resolved, as the post was 6 days old, but in case you'd just 'back-burnered' it for other work I thought I'd post what I found. I'll stash the newly-learned info away in case I meet such errors.
I don't have any exposure to Tahoe yet. I'm very slow to upgrade. I have one client who upgraded without discussing with me (his iPhone auto-updated and he could not backup to his MBP without Tahoe). It broke a bunch of stuff with FM and others, but it's largely resolved now.
I, too, have a dev server on Ubuntu (24.04 LTS ARM) which has been great. I set it up mostly to get used to that environment, since I'm otherwise pretty Mac-centric. It's mostly been very smooth.
Glad you figured out the issues.
My top tip for making the transition to Ubuntu servers. Have a machine running Ubuntu with full GUI to manage them. Some things are so much easier in the GUI.
My Ubuntu FMS server is more of a 'lab' deployment. I purposefully run it without GUI (to hone my CLI skills) as I've developed a "fms_toolkit' of shell scripts and cron jobs; receiving daily status emails, checking restart recommendation status, scripted FMS restart routines, and scripted Ubuntu update and upgrades. In this case I'm avoiding the GUI, but I do have other Linux deployments with GUI and it's definitely less geeky. The latter are not dedicated DB servers though.