I know I’ve seen this error a few times in other posts. But getting this with a client and can’t seem to get it working.
macOS: 15.4
FMS: 20.3.2
We have restarted the httpserver, ensured full disk access is set, made sure to type /otto/, the https://edd-sl-proxy.geistgate.com is reachable. Threatlocker is installed but was in training mode, so shouldn’t have been blocking anything.
Ideas?
Usually when I see this it means that OttoFMS is not running. Have you checked if the ottofms service itself is running? Service info
-Kyle
Otto is running. After some playing around, we found adding port 3061 to the url worked.
Strange. Its possible that the reverse proxy is not being added properly. Do you see anything in the otto-info.log during the startup?
-Kyle
I will look again when I talk with them today. We figured that out because there was an entry in the log:
"2025-04-08T21:37:18.160Z info Listening on http://localhost:3061”
I’ll try to grab the full log today.
otto-info.zip (1.4 KB)
Here is the info log. It looks like the reverse proxy was set up.
Are you going to url/otto or url/otto/? There’s a funky thing with the Mac reverse proxy where it requires the final slash to do the redirect.
-Kyle
url/otto/
We tested it with both. But the only thing that worked was url:3061/otto/
It did look like from your log that it found two different paths for the config files, can you confirm that those paths both point at the same spot? You can also go to the apache config files for FileMaker Server and double check that the Otto pieces have been added. There should be an httpd-otto-proxy.conf file and a section in the httpd.conf file that imports otto as well.
Is there a firewall or something on the server that might be preventing access?
I’ll try to take a look tomorrow and see what I can find. My meeting with them had to be pushed off.
Turns out they have a mirrored backup drive attached to that machine. So that path to X10 Pro is the backup drive, and that is were it’s trying to deploy to/from. ( and yes, they have ThreatLocker on the server, so that is also adding some challenges )
You might want to try manually setting the FMS path using the env variables. It will make sure OttoFMS is getting the right set of FMS files. You shouldn’t need to add the username and password in there, just the path.
-Kyle
Still the same result. Seems to work if they use the port number.
Then on another server, they are having a different problem:
You don’t have permission to access the requested directory. There is either no index document or the directory is read-protected. You don’t have permission to access the requested object. It is either read-protected or not readable by the server.
From what I can tell, the permissions look ok, but I don’t have direct access so I can’t poke around more.
otto-info.log.zip (2.5 KB)
The “Can not connect from a remote address” error is the one that is supposed to fire if you attempt to connect via port 3061. Are they trying to use 3061 on that server too?
-Kyle
Have they done any customization to their network setup on these servers? Any changes to the Apache configs?
-Kyle
No changes to Apache. It is just a mac mini or a mac pro with Threatlocker installed. The network, maybe. There is a regulatory data piece, so the security is a lot tighter.
Not using port 3061 on this second server, leaves us with the same error as the 1st server.
Well that is strange. Its possible that Threatlocker is messing with the routing to the port? Do they have exclusions or something set up for filemaker? It may be kneecapping the connection to OttoFMS. You may want to see if they’ll set up exclusions for OttoFMS.
Beyond that is there any funky setup on the servers? Or just normal with Threatlocker?
-Kyle
Just normal with Threatlocker. But I have to wait to see how far they want to dig into the problem. I’m just consulting to help get them up and running. If I find more helpful info, I’ll come back with it.
