FM Data Migration Tool bug or feature fmmigration extended privilege required?

Using the Data Migration Tool, FMDataMigration -version 19.1.3.315 on a Mac running macOS Catalina 10.15.7

EDIT:
UPDATE: I have been unable to reproduce the issue, after more testing. - See below. Good news is that everything is working now.
End of EDIT.

I have been trying to get the data migration tool to work using [Full Access] account credentials on an encrypted file without success. Following the documentation I created an extended privilege set with the keyword fmmigration, and assigned this to a user, in both files before cloneing. Using this special user's credentials, not the [Full Access] user credentials, the data migration tool work as expected.

So, I have things working now, but I was wondering if this is a bug or a feature? If it is a feature it seems to be undocumented. - Has anyone else had this issue? Or is it that the tool no longer works with [Full Access] credentials on encrypted files?

I did a test on an unencrypted file with the default Admin [Full Access] user, no password, and that also worked fine. Does an encrypted file now require a user with the fmmigration extended privilege?

1 Like

As long as you are including the encryption password in the command, it should word. Do this all the time.

Thanks @jormond - I did include the encryption password in both cases.

  • Using [Full Access] account credentials plus encryption password does not work.
  • Using user with fmmigration extended privilege account credentials plus encryption password works fine.

encryption password - is not the issue I am having

If you add the verbose switch, what error are you getting?

I just tested it, and it worked as expected.

Attached is the sample Contacts file.
I encrypted it.
Saved a Copy as a Clone ( make sure you do not open this file )
Copied the DMT to that folder ( just for convenience )
Ran the below command.

~/Desktop/DMT_Test/FMDataMigration -src_path ContactsEncrypted.fmp12 -src_account admin -src_pwd admin -src_key x9CT@4nEXrfCiefAk -clone_path ContactsEncryptedClone.fmp12 -clone_account admin -clone_pwd admin -clone_key x9CT@4nEXrfCiefAk -ignore_fonts -v

User: admin
Pass: admin
Encryption Key: x9CT@4nEXrfCiefAk

DMT_Test.zip (590.7 KB)

1 Like

@jormond - thank you that works fine, as expected. I will keep working on my 2 files that do not work as expected to see if I can find the issue. Very strange!

If you add the verbose switch, what error are you getting?

this was with my problem files - not the test file you sent:

I will have another go tomorrow (getting late here) and let you know - basically the error I was getting was with authentication of the migrated file I believe.

Are there any special characters in the password? Sometimes characters like % especially cause issues.

3 Likes

yeah, try quoting your password in the command (I think single quotes in bash/zsh)

3 Likes

@jwilling - I am using zsh. using single quotes around the parameters is a good idea. In this case though it does not help, this was not the issue. See below...

I seem to have found the issue and solved it:

The [Full Access] user password started with a number. Changing the [Full Access] user password to start with a letter has solved the problem.

I had the same problem on 2 different files, both using a [Full Access] user password starting with a number. In both cases changing the password to start with a letter has fixed the problem.

I have not tested with a [Full Access] user password starting with a symbol - I do not intend to test this, I'll stick with a letter.

Note that the [Full Access] user password that works does contain these symbols .*

Note that the password for the special user with the fmmigration extended privilege set does start with a number and that works fine - this just seems to be an issue if using a [Full Access] user account starting with a number.

My solution: If you plan to use the data migration tool with a [Full Access] user credentials make sure the password starts with a letter!

3 Likes

a bit more information in case this helps any one else

@jormond

If you add the verbose switch, what error are you getting?

Couldn't open the source file because "(212): Invalid account/password."
Source: Contacts.fmp12

Are there any special characters in the password? Sometimes characters like % especially cause issues.

This was not the issue in this case, but are you saying don't use special characters in a [Full Access] user password? Or are there specific special characters that should or should not be used? Is this documented somewhere?

There are some special characters that can cause an issue when being processed in FileMaker itself. Actually, your first-character-number password falls into this category. Most are fine, and FileMaker handles it fine. When getting into some CLI commands, it all depends on how the password is processed. It seems in this case, the command gets confused by a number being the first character.

1 Like

the command gets confused by a number being the first character.

I guess so!
Thanks for your help.

Interesting that it is only a problem when the user is [Full Access]

We had a similar problem using a ‘£’ sign within, not at the start, of the EAR password. I reported this on the original forum, but have no idea whether that post still exists.

From memory, we also had problems migrating from a non-encrypted file to an encrypted file and issues with missing externally referenced files that resulted in the log telling us the file was not safe to use.

Everything was reported to FileMaker at the time.

1 Like

It is weird. I agree. Worth reporting to Claris as a bug.

2 Likes

Yes please report this to Claris with a sample file.

That’s an annoying bug!

2 Likes

Sorry this took a while... After some sleep and some coffee I did some more testing. I am unable to reproduce the issue using different files today. I don't plan to report this as a bug to Claris at this time as I am unable to reproduce the issue.

The good news is that everything is working now.

I feel like a fool for time wasting here.
Thanks for all your help.

2 Likes

Not a waste at all. We all run into those types of bugs.

2 Likes

Then I'll just say thank you, and everyone else, for your generosity of spirit.

1 Like