Product and version
Filemaker Server 184.108.40.206
OS and version
OS X EL Capitan 12.11.0
Browser and version (for WebDirect only)
I've had this issue reported to me from users using Webdirect to access filemaker modules on Google Chrome. I did not record the version.
We are running the server on a:
Mac Pro (Late 2013)
Processor: 3 GHz 8-Core Intel Xeon E5
Memory: 32 GB
Users occasionally report a file lock error when trying to edit fields on while accessing a file from WebDirect:
We run a diversity of WebDirect files for users to access remotely, and utilize two main log-in systems for WebDirect. 1) Users are validated against an external LDAP server. 2) Users are given a sign-on URL for web-direct, which passes a script param with encoded log-in details. They then browse as Guest, but have access to unique content based on the param passed in the URL.
The example above is a user of type #2, however this problem has also been observed for at least one user with LDAP credentials.
When an Admin inspects the Activity log on the server, we can see the Webdirect client. However, a forced Disconnect attempt never releases them. The result is a "ghost" user, that locks the file and prevents any others from editing it.
The generation of these ghosts is thankfully rare. On our busiest WebDirect files we see dozens of unique users a day, but only once a week or so does a ghost get generated. Users who report the file lock error, have usually been logged out due to a timeout. Our WebDirect files have a 15 minute inactivity timeout.
How to replicate
By my eye, it seems to be an artifact of timeout logouts on WebDirect. If you bait timeouts on a webdirect site, by visiting the Webd site and waiting for a timeout, it seems like eventually a ghost user is created when the client fails to release from the server, and can not be disconnected by the Admin. I don't know what determines if the client will be released or not - in exploring on my end it seems random.
We discovered this bug initially while designing an important WebDirect service that would be shared with users outside our internal, trained, FM users. These outside users would be logging in using a URL pass log-in token as Guests. To resolve this problem, we made the WebDirect facing layout a generic space that loads data based on globals. This lets us create a new record for each log-in instance and totally mask the meaningful data from file locks by calling it externally to the user's layout with globals. In other words, we sandboxed the WebD UI from the core data, so that if a file lock occurs it doesn't not disable editing to other records that access the same root data. This is our recommended workaround, but requires a bottom up schema design.
In researching this issue, I discovered we were behind a version on our FM Server 16.0.4 was released in Feb. As soon as possible, we will be taking our server offline and updating the OS and FMS versions. I'll report that if the bug is resolved after that update.
We've also found that restarting the FM server does release these ghost clients, however, we cannot easily drop service to our users to fix the issue this way.
I've seen similar fail-to-release-ghost issues reported before for v 13-15, and wanted to provide more information about how this is continuing in FMS 16. I also wanted to offer a detailed write-up so that in case a 16.0.4 update to FMS resolves this bug, I can advertise it here.
More to come.