I can finally report resolution of a longstanding problem, in hopes that it might be useful to someone else.
The short version of my client’s sad saga, is that container documents in secure external storage were damaged by the IT company’s monthly restarts of the FM Server VM for OS patches. Further troubleshooting determined that even restarting the FM Service would completely destroy the container documents.
The documents were stored with all FM data on drive E. New test databases on Drive E experienced the same fate, where server or service restarts damaged the container documents. Further testing showed that a fresh copy of the same test database, when installed on Drive C, survived restarts with all container documents intact. New testing on Drive G reproduced the same problems as on Drive E.
The client’s IT company created a new VM, and we installed using the same setup as on the production system: OS and FM Server on Drive C, Data on E, Backups on G. The same problems occurred on restart, i.e. all container documents damaged beyond any possible access.
Next we uninstalled FMS 16 and installed FMS 17 on the tester VM, and discovered during configuration that container document storage was not allowed nested in Drive E; instead, FMS would support only container storage at the root level of the external drive. For the first time, restarts did *not* damage the secure external container documents. And we had our clue: try the container folder at the root, not nested.
Then we uninstalled FMS 17 on the tester VM, and reinstalled FM 16.0.v4, but this time we put the container documents at the root on Drive E. Voila! No container documents were harmed by any restarts.
So the moral of the story is that secure external container storage, on FMS 16 on an external drive, needs to be in a folder at the root, not nested. So we went back to the production system, changed the location of the container folder, and no problems have occurred after any restarts.
Thanks to all who helped along the way, and especially Wim Decorte.
Environment: FMP 16.0.3 running on the client agency’s “RDS Farm”, a Windows 2008 VM. 35 users. Server 16.0.4 hosted on Windows Server 2012.