Deployment often fails on first try but succeeds on second shot when done manually

OttoFMS
1

Hello,
we have a rather huge deployment job on Windows Server 2020 (about 100GB).
From the developer server we start a migration to our production system and often get the following error:

Couldn’t open the source file because "(803): File already open but single user [extended error (20402): File permission problem].

The file in question is not always the same (of about 20). In the end the deployment fails and we start it right away manually. The second deployment succeeds.
I guess not all files are closed by the server when the deployment starts.
Would it be possible to have a grace/ waiting period to make sure all clients are disconnected?
Does OttoFMS check if all clients are disconnected before starting the deployment?
Thanks for any comments, Stephan.

2

Hi Stephan,

Welcome to the community. :slight_smile:

If the files don’t close OttoFMS will abort the deployment. The error will say something like “Couldn’t close all the files”. So that isn’t likely to be the issue.

If you could send us the debug info for the deployment that fails we could get a better idea of what is happening.

Here is how you do that

And if you can turn on Debug Logging before your next attempt that would be helpful, and send us that Debug Info set that would be super helpful.

You can Direct Message the logs to me here.

Thanks

Todd

3

Hey Stephen,

I would also double check that the FileMaker Server and OttoFMS folders are excluded from any Windows Defender or other anti-virus scanning, it could be that one of those softwares is opening the file (with the filesystem, not with filemaker) to check the contents for malware. That can cause OttoFMS to fail to open the file when running the migration.

-Kyle

5

Hello -)

I got the logs. Thank you.

So something is opening those files after they have been closed by FileMaker server. The odd thing is that it suggests it is FileMaker. Single User mode is not just an OS level file is locked kind of a thing.

Are you running progressive backups?
Or is there any other backup process running?

Todd

6

Another thing you could try is running the build ahead of time.

Since it always works the second time when the files are already there, this should work. You can run a build that pushes the files to the server so they are waiting there. Then run the deployment.

That doesn’t solve the mystery but it should get you passed this sticking point.

Let us know what happens.

Thanks

Todd

7

Thanks for the virus scanner tip.
We will tone down its activity after the next deployment and show if it has any effect.

8

Thanks for the workaround hint regarding builds.

We just upgraded to 1.8 and the deployment on our test system went thru.
On Thursday we’ll cross our fingers and see if it works on the production system as well.
If not we’ll step down the virus scanner activity.

Thanks for your help, Stephan.