This might not even be a bug/issue -- it's possible this is expected behavior, but I thought I'd put it here in case it's affecting anyone else, and/or is something that could be fixed.
Product and version FileMaker Server 14.04
OS and version Windows Server 2012 R2
When using Perform Script on Server, under some circumstances, changing the preference order for the path to an external file causes some functions to fail (in this case, a find). In my case, this only affects users with limited permissions (calculated).
There is an interface file which connects to many data files. The script is contained in, and kicked off by, the interface file. All the files are on the same server. Both the script that initiates the Perform Script on Server and the script performs the script on server are set to run with elevated permissions.
The script that creates a child records, sometimes in great quantity, so we use Perform Script on Server to get a vast performance improvement.
The user is on a layout display data from a data file (we'll call it Data File A).
The local script sets the record ID as a parameter in the server script, since the Server-side script doesn't have any other way to know which record you were on.
The server script then navigates to a particular layout (which views the same table in the same file as the user was on, but is not the same layout), omits all records (so found count = 0), and then performs a find for the ID number.
I recently changed the order of the entries in the path to Data File A (in an attempt to solve a different problem, which it didn't). The change I made was to move the "file:" reference to the bottom of the list, with the "fmnet:/" reference at the top of the list.
Users with non-calculated permissions on Data File A were not affected by this change.
All users (including those with calculated permissions) could still the correct records and use the system properly in all other circumstances other than Perform Script on Server.
Users with calculated permissions on Data File A could no longer use the script in question, because the Find for the ID (primary key) would fail. (Which was captured by the script, which then kicked the user out with a more useful error message).
I added some text to the Return value of the script, and was able to determine that it was still successfully receiving the parameter, and navigating to the correct layout. However, the find would fail resulting in still having a found count of zero.
How to replicate
Use calculated view permissions on an external data source, set an "fmnet:/" path at the top of the list in External Data Sources, and try to access those records using Perform Script on Server.
Workaround (if any)
Set a "file:" path at the top of the list