I had an odd one trying to using the CLI on windows to upgrade Otto - I even tried the manual method of uninstalling and reinstalling, but kept getting error that it wasn’t a valid application.
I copied the uninstaller off another windows server and then was able to run the CLI on this server. But noticed the same issue that the uninstaller is 0kb
I believe the uninstaller is a symlink to the Uninstaller.dat, which is why its 0 KB. That’s probably why copying it broke it. Did you hit an issue running it manually or was there an error on the CLI install? Could you share the error?
threat locker is a good bet, I haven’t seen that before so it might be removing the uninstaller as a detected threat? We’ve had similar problems with NSSM on some servers
Thank you for giving us a call earlier. I remoted into the App Server and saw that Threatlocker appeared to be blocking the new update for OttoFMS. I reached out to my team about getting it unblocked, but our agent was reporting that there might be a virus inside of the installer. Please allow us a little bit of time for us to sort this out, and we will reach back out to you once we have cleared the installer.
Do you think setting on their end are too restrictive?
After a macOS system update (minor or major), OTTO FMS frequently stops functioning correctly and requires a full reinstall via Terminal to restore normal operation. This appears to be a consistent pattern across multiple servers.
Expected behavior: OTTO FMS should survive macOS updates gracefully, similar to other background services, or at minimum provide a clear in-app repair/reinstall option.
Actual behavior: Post-update, the only reliable recovery path is running the installer again from Terminal, which is not documented prominently and adds unnecessary friction for production server maintenance.
2. Inconsistent “Full Disk Access” Privacy Entry Across Servers
In System Settings → Privacy & Security → Full Disk Access, the OTTO FMS entry appears inconsistently across machines:
On some servers it correctly shows ottofms-macos-arm64
On some Apple Silicon servers it appears with a generic or non-architecture-specific name (not arm64)
On some servers no entry appears at all, yet OTTO FMS appears to function normally
Concern: When no entry appears, it’s unclear whether Full Disk Access is actually granted or silently missing, making it difficult to audit security posture or troubleshoot access-related issues. The behavior should be deterministic and consistent regardless of how the service was installed or whether macOS was updated post-install.
When navigating to the FileMaker Server backup folder from within OTTO FMS, the interface hangs with a spinning wheel and the folder contents are inaccessible. The root cause appears to be incorrect or missing privileges on the fmserver (FileMaker) user for that directory.
Workaround (required repeatedly): Remove the fmserver user from the backup folder permissions and re-add it. After re-adding, access is restored.
Problem: This workaround should not be necessary — especially after macOS updates or OTTO reinstalls. The installer or service should reliably set and preserve the correct ownership and ACL permissions on the backup path. This is particularly disruptive in production environments where the backup folder path is managed by FileMaker Server and shouldn’t require manual permission surgery.