We have a server running Windows Server 2019, FileMaker Server 20.3.2 and Otto FMS 4.3.0. When accessing the FileMaker Server area in Otto console the screen loads for a bit but then errors out with a 500 error.
We’ve tried restarting all of the usual suspects (admin server process, Otto process, entire machine) and have tried re-installing OttoFMS (albeit without removing the directory in program files). The Otto logs indicate that the Admin API token was refreshed successfully but nothing further relating to the 500 error.
Is there anything else we can try prior to blasting away the entire OttoFMS folder in program files?
OttoFMS is failing when it is trying to get a list of FileMaker from the Admin Api. I suspect that something is amiss with the FileMaker Server Admin Server component.
Can you log into the FileMaker Server Admin Console?
try using the terminal and enter fmsadmin restart adminserver
Yes it’s just the FileMaker Server section. The browser console shows the Admin API is returning 502 error. I’ve tested the Admin API call in Postman and got successful responses.
Further to @jamesatdf post about this particular server, I should also point out that this is also occurring on a second server now (Windows Server 2016 Datacenter, FMS 20.3.1.31).
I believe the FileMaker Server tab in Otto was working fine up until the point we updated Otto on both servers to 4.3.0 at which time this started happening. No changes in version of FileMaker Server have been made in the interim.
Thanks for the screenshot. Unfortunately it confirms what we already know. OttoFMS is not able to make a call through the Admin API to get databases.
Are both the servers that are having the problem windows 2016?
To rule out a problem with the FileMaker Server Admin API and Admin server. Could you try running the commands to list databases with the fmsadmin command. And also try make a call straight to the Admin API go list databases?
The first server James mentioned is Windows Server 2019, while mine was 2016.
On both servers I can successfully run fmsadmin list files while in powershell.
I am also able to execute the data api call on both servers in browser & postman without issue, as well as from my own machine. The 2019 server one did give error code 9 for insufficient privileges, however that’s just because I did not provide any auth creds in the header for listing databases but otherwise it does work.
Well none of this making much sense I am afraid. Possibly it is some kind of caching issue. Maybe try from a different browser or browser profile? or Log our completely from the OttoFMS Console.
I don’t think completely uninstalling and re-installing but you could try.
You could also try reverting to 4.2.4
If you want to sign up for an Office Hours sessions we could maybe poke at it together.
Some further interesting things to note. If when I first go to the databases tab, it sits with the spinning icon for about 7-8 seconds… BUT if while it is loading, I click on “Clients” tab a couple of times , then as soon as databases finish loading, it will jump to clients tab. I’m then able to go back to the databases and see them all, and it all works fine.
If however I don’t click on clients, it will give me the 500 page once the databases load. The first time I tried this, I very briefly saw the databases display (for like 0.05 seconds) before the 500 page. So they do appear to be loading, but the 500 page just shows up immediately (unless I quickly switch to another tab first).
Morning,
Same here, on both servers. Windows 2019 Server, FileMaker Server 20.3.2.
The web interface takes a long time to load the data, flashes shortly with the resulting list, and then immediately switches to the “500 error” page.
FYI
As weetbicks points oout, fiddling with the navigation while the database list is loading (no real system found yet) can result in the database list finally displaying. Once it loads, it seems to be cached, and I see no issues afterwards navigating between the vertical tabs en the horizontal tabs.
After a test upload, the file is immediately visible in the list, so the list refreshes correctly. Same goes for the list after deleting.
I have the same issue. Both servers are on Windows Server 2019 Standard, FMS 20.3.2, OttoFMS 4.3.4. Fiddling with the navigation did solve it but was a bit hit and miss.
