We are getting the below error when trying to deploy from Database Y to Database Y from the server A.domain.com to B.domain.com
UnauthorizedError: Token is missing, redirecting to login
FMS 20.3.2.205
Ubuntu 20.04 OttoFMS 4.3.5 was the version we had when this issue first occurred
Both FMS servers (and Linux) have been restarted - issue persists OttoFMS 4.6.2 is the version we updated to and the issue persists
Both FMS servers (and Linux) have been restarted - issue persists
SSL certificate is the same on both servers and both are under the same top level domain.
Both Servers have plenty of storage
â
We tested by creating a new sample file and migrated without issues (regarding API Keys) and also confirmed that Account credentials are correct and work for both files.
Furthermore - we never got past the Starting data migration phase
Happy to share logs with the Ottomatic development team - kindly advise which logs you need and how to share them.
That error is from a user attempting to access the OttoFMS console and being redirected to the login screen, it will not appear due to a deployment. In your logs it looks like your deployments are being aborted, is there an error in the deployment that is prompting you to abort them?
It does also look like in your logs there may be some corruption on your file, you could try running recovery on them to try and fix it.
Thank you for your reply.
Understood regarding the redirect login error - thank you - I am adding a screenshot of the logs higher up at the end of this reply in the hope it helps.
We aborted the deployment(s) as nothing was happening and as mentioned even though a long time has passed (about 30 minutes) and we never got past the Starting data migration phase on the web view.
We ran a recovery and we only have 2 types of errors:
Item count changed from 10193 to 11058 in: library catalog âxxxâ but we did not see any changes to the data nor the table (repeats 2 times)
8487/8476 which is Reset table view/This item changed respectively which from what we read online it says we can disregard these errors
Is that the FileMaker log there? It looks like the DMT is throwing some sort of error back at you, is there an error message at the top of that stack its giving you? If the DMT is erroring out it is likely due to some sort of corruption or other issue with the file. @toddgeist may have seen this error before.
The migration is failing before it even gets going. We should handle that better. But I suspect the file is corrupt in a way which makes the DMT unable to use it. You could try running a Data Migration manually use the command line on the same server. The Data Migration tool is in the FileMaker Server application bin directory. I suspect it will fail there as well. But it would be good to know.
But either way you have two tools suggesting that the file is corrupt, recover and the DMT. You are probably going to have to resolve that.
We ran a recovery on our files and we got the attached message that says â9 Items Modifiedâ and all the errors we saw on the Log file were error 8487/8476 which is Reset table view/This item changed.
Based on Toddâs suggestion, we did a manual and local migration using the FMDataMigration tool and the process was completed successfully. It took around 38 minutes, but it did finish. While with Otto we are stuck on Starting Migration and the process does not go further. Any chance these errors affect Otto deploy? Just to mention, 8/9 layouts where this error shows are 6months+ layouts and we have had successful deployments during this time using Otto.
OttoDeploy and OttoFMS use the DataMigration tool that is installed on the FileMaker server. So the version of the DataMigration tool that is installed on your server maybe different than the one you are using locally on your computer. We have definitely seen that different versions of the Data Migration Tool running on different operating systems have different tolerances for file corruption. We know for certain that Linux is less tolerant of corruption in Files than either windows or mac is.
That is why I suggested doing a manual migration ON THE SERVER using that version of the DataMigration Tool. Doing it locally with a different DataMigration Tool isnât a good test as it is not the same environment as your server.
I had not noticed the âSERVERâ part of your original message.
We did it on the server and the migration completed, please see attached screenshot.
Would it be worth removing in full Otto from the server and setting up again?
However, the migration with Otto did work with a small file that we tested during the first troubleshooting steps.
Could it be an issue with the total size of the files?
Ok well that is good to know. That rules out the potential issue with difference in Data Migration tools and environments.
I doubt it has anything to do with the total size of the files. Although it possibly could have something to do with the amount of space on the drives.
What does the OttoFMS show as the error? Does it just say âmigration failedâ?
