I saw this feature a few versions ago but never got it to work. Nothing at all is copied. Never. On every server I try this, even Windows servers. Is this really working? This is about managed container data, right? Or am I understanding this wrongly?
Hey Peter,
This will copy external container data for files includes in the deployment that are being copied from the source to the destination. So if you are running a migration it will not copy container data, but if you are installing or replacing an existing file it will copy container data.
Additionally, if you are using a build you made ahead of time, that build will need to have the container data. If you are using a Just in Time build it will automatically be set to grab the container data, but pre-made builds don’t necessarily have the container data in them.
What is your build/deployment setup for these deployments that are not copying over the container data? Where is the container data stored?
-Kyle
Hi Kyle,
Typically, after a deployment that migrates files, I run a second deployment that does an install/replace back to development, so I have recent data to work with. Having the container data copied back as well was an option I looked very much forward to. For customers like the one today, I run it in the morning before starting my development.
In this very simple setup I had today, with only 1 file, this “copy back” deployment is done on the same server using the default JIT system, the “File Name on Destination” is renamed to “Development”. That works fine. There is one option active, and that is the “Transfer Container Data” - see the screenshot in the OP.
The FileMaker external container data is stored in /usr/FileMakerContainerData/ in the RC_Data_FMS Folder. All folders have fmserver:fmsadmin as ownership settings and mode 775. There is about 9GB of container data in the production folder, and nothing is copied.
I found out why this doesn’t work while wriiting this:
The ott-info log reports
2025-10-27T08:50:04.581Z info Build jit_build_3230057dd2e314b9a6fcaedf - moving files - {{production filename}}: RC_Data_FMS folder not found for file {{production filename}}
A bit concerning it says “moving files” and not “copying files”, but that is just nitpicking of course. The OttoFMS programme code doesn’t investigate the “Container Data Folder 1 Path” that is configured in the FileMaker Server Admin console.
The reason for configuring this additional container data path, is that there is no other way of keeping FMS from backing up all container data if you keep the container data in the default database folder. And BTW I wonder why Claris designed things that way.
Because I do this on every customer FMS install, this explains why this new OttoFMS feature never worked for me.
Hey Peter,
Do you have the “Backup Container Data Folder 1” setting turned off in the FileMaker Admin Console? OttoFMS is using a FileMaker backup to copy the files, and if you have that setting turned off it will not copy the external container data when it creates that backup.
If you would like to pull the container data (and the .fmp12 file) directly from their existing location without turning on that setting, you can toggle on the option to close the files during the build. This will close the files during the build, copy them and their container data directly, and then reopen them. You can find this setting in the build options menu in OttoFMS. If you are planning to run this immediately after a deployment to production, there is an option you can toggle in the first deployment to keep the files closed when the deployment ends. that will ensure no users open the files between when the first deployment finishes and the build for the second starts.
The reason it says it is moving files is because it is! When the backup is made OttoFMS moves the files from the backup folder into the build folder in the OttoFMS Outbox.
-Kyle
Indeed, the whole purpose for the extra container data folder was to have FileMaker Server not back it up each and every hour.
Now I understand. So OttoFMS is simply instructing FMS to make a backup, and we encounter the rule as defined in the FMS console.
Your solution to close the file first looks like the best workaround. And I understand now that the log reflects what happens internally in OttoFMS.
So probably a deployment scenario where the files are not re-opened in the first part, followed by an install/replace is the way to go. Haven’t looked at it while writing this, but if that works, that would solve it completely.
Thanks Kyle !
