This is a question and a request at the same time.
I would like an option to explicitly say if I want to save the encryption password when reopening the file that was migrated. This would remove any doubt of what is happening for that.
It comes from being a little confused as to what happen at the moment. I can’t find why, but most of my installs / replace / migrations, with any combination of having the same encryption password on the source and destination or different, are totally fine. We reboot servers on the weekend and everything reopens.
Then sometimes, like once a month, our support will contact me saying X file was not reopened because encryption password was not saved on server.
I’m wondering if I should add to the procedure to manually go close and reopen the file every time to see if it’s still saved, which would be a little annoying. Specifying it as a deployment option would be great! 
Hello,
Thanks for the question. It does sound confusing.
Looking at the code base, it looks like we always save the key. Also the fact that this randomly happens on the same deployment suggests that something else is happening. I’d like to figure out of that is the case.
Can you confirm that this is always the same deployment and the that the encryption keys are not changing between deployments?
Thank you
Todd
1 Like
Great thank you, knowing that it is fixed to save at the moment is a good information to inspect further.
I confirm that in this case, it was the same encryption key. This specific migration is installing a copy of the same file on the same server.
In the past, it was often a different password, on two servers. All in all, it works more often than it does not, as we’ve done dozens of migrations. I would lean towards another server manipulation causing the problem, but it’s bugging me that it usually happens when I deploy…
One last question.
How does the error show up for your support team? Is it in OttoFMSs logs or is it from FileMaker Server’s logs.
Knowing the specifics of the error, might help us track down any edge cases that might be out there.
Thanks
Todd
On FMS, after services open, error 939 (SECURITY: Database could not be opened: incorrect encryption password.). Unsure if not knowing the password because not saved produces the same error of incorrect password.
The full timeline is :
- Install Wednesday without error.
- People using the file Wednesday, Thursday and Friday.
- Sunday : automatic server reboot with "Automatically open databases that are in the database folders.
Not sure if this is helpful or not… but in our experience, the option to save the encryption key is flaky at best. Sometimes it works, sometimes not. Sometimes it’s fine through several reboots, and then all of sudden it doesn’t like the key anymore. And sometimes it happens to this file, and sometimes it happens to that file.
Drives us mad!
I’ve heard it’s a “known issue”, and I’ve also heard “it’s fixed in this version” several times.
I’ve also read that clearing all of the keys and re-entring them will solve it. Tedious if you have lots of files. And still the issue returns eventually.
Hopefully FMS 2024 has the fix, for real, this time…
1 Like
I have this a lot, it’s been a problem for a while, even with the previous Otto version, especially under MACOSX. Now I keep losing the encryption key and have to reset it on the servers on Sundays when maintenance work is in progress.
I always migrate data to databases that have their own encryption key.
The migration always runs smoothly, but the databases no longer start after a reboot from the server or simply stopping the database and restarting it.
I then have to delete the encryption ( clear encryption keys) and re-enter it.
This on MacOS and Linux servers. I cannot judge this on Windows servers.
1 Like
It sure is good to know there are other people in the same boat! I’m wondering if this has to do with the way special characters are treated during the commands. Maybe it’s doing okay for opening the file, but the savekey option writes it wrong wherever they put it.
We do always have a mix of letters, numbers and special characters. Is it the same for you guys?
Hey y’all,
I’m loving the discussion here, thank you all for your insight!
The option to save the key is passed from OttoFMS to the FileMaker Admin API as part of the call to open the files at the end of a deployment. The option is a true/false toggle which tells the FMS api to save the key we send or not. Any handling of special characters or saving of the key is then left up to FileMaker rather than OttoFMS.
I suspect that this issue is from within FileMaker as @flybynight suggests, as we are handing off the information to FileMaker and they are then handling the saving and retrieving of the key later. If our handling of the encryption key was not working then the files wouldn’t be opening in the first place.
-Kyle
1 Like
FYI, I’ve seen issues and reports when the same encryption key is used for more than 1 file. Could that be the issue you are experiencing @m.desmarteau ?
Interesting, I’m trying to think of the other times and I don’t think it was the case, but it certainly is for this time, I had to deploy two different files with the same base and same encryption key!