OttoFMS 4.14.0 and 4.14.1 on Ubuntu, ARM architecture - service fails to start

quarfie · December 22, 2025, 3:14am

Edited 2025-12-22: The problem is specific to ARM architecture and OttoFMS versions 4.14.0 and 4.14.1. Version 4.13.1 has no issue.

Copilot helped make the following problem report and seems pretty certain this is an issue with the installer. Are others not seeing the same issue?

Subject: OttoFMS 4.14.1 Linux installer creates invalid systemd service file causing NOPERMISSION errors

Severity: High - Service fails to start via systemd restart but works when started manually

Description:
The OttoFMS Linux installer (version 4.14.1) creates a systemd service file with configuration errors that cause permission-related failures when restarting the service through systemd, though the service runs successfully when started manually.

Root Causes:

Systemd unit file bug: After and Wants directives are incorrectly placed in [Install] section instead of [Unit] section

Exit code 4/NOPERMISSION: Service exits with permission error during automated restarts, triggering systemd rate limiting

Rate limiting: After 5 rapid restart attempts, systemd blocks further starts with “Start request repeated too quickly”

Symptoms:

Service fails with status=4/NOPERMISSION when restarted via systemd

Manual start (systemctl start) works correctly after stopping

Service file shows configuration warnings about unknown keys in Install section

Service File Issue:

Environment:

OS: Ubuntu 22.04 LTS (ARM64)

FileMaker Server: 22.0.4

OttoFMS Version: 4.14.1 (binary dated Dec 10, 2024)

Installation Method: curl -fsSL 'https://downloads.ottomatic.cloud/ottofms/install-scripts/install-linux.sh' | bash

Reproduction:

Fresh Ubuntu 22.04 ARM64 with FileMaker Server 22.0.4

Run OttoFMS installer

Attempt to restart service: systemctl restart ottofms-proofgeist-com.service

Service fails with exit code 4/NOPERMISSION

After failure, run: systemctl stop ottofms-proofgeist-com.service && systemctl start ottofms-proofgeist-com.service

Service starts successfully

Back to Jason:

Although the above says the service starts successfully after a manual stop/start, I still get 404 Not found on /otto

I also tried this on Ubuntu 24.04 (ARM).

Pretty sure I also got this result on 24.04 (ARM) with FMS 21.1.5

Here is how I install Otto with Ansible:

---
# Install or update OttoFMS
- name: Install OttoFMS
  become: true
  ansible.builtin.shell: |
    set -o pipefail
    curl -fsSL 'https://downloads.ottomatic.cloud/ottofms/install-scripts/install-linux.sh' | bash
  args:
    executable: /bin/bash

- name: Ensure OttoFMS data dir exists
  become: true
  ansible.builtin.file:
    path: /opt/OttoFMS/data
    state: directory
    owner: fmserver
    group: fmsadmin
    mode: "2775" #setgid: keep group on new files

- name: Install OttoFMS License Key
  become: true
  ansible.builtin.template:
    src: OttoFMS_license.j2
    dest: /opt/OttoFMS/data/license.json
    owner: fmserver
    group: fmsadmin
    mode: "0640"
  register: ottofms_license

- name: Restart OttoFMS
  become: true
  ansible.builtin.service:
    name: ottofms-proofgeist-com
    state: restarted
  when: ottofms_license is changed

The second step is new. I never used to need to create the data directory. Unsure if the installer changed or a new version of Ansible no longer creates the directory automatically on the next step. Edit: It’s probably because when OttoFMS is working, it creates the data directory on first start.

quarfie · December 22, 2025, 11:19pm

The problem is specific to ARM architecture and versions 4.14.0 and 4.14.1.

Version 4.13.1 has no issue.

john_r · December 23, 2025, 11:24pm

Its not Ansible, it’s Ubuntu for ARM, see my other answer on the other thread

barbar09 · January 5, 2026, 5:53pm

It looks like the unit file regression and an extra permissions tripwire when ottofms tries to touch /opt/OttoFMS before the data dir exists are happening here on ARM with 4.14.x. 4.13.1 works because the service starts up without any problems and makes its own data path the first time it runs.

What helped me get out of the 404 + restart loop was:

Make the unit file so that After=/Wants= goes to [Unit]

Before systemd ever starts ottofms, you need to manually mkdir -p /opt/OttoFMS/data and chown fmserver:fmsadmin.

Instead of restarting the first time, use systemctl daemon-reload and then systemctl start.

After that, ottofms stops giving the NOPERMISSION error on ARM, and the /otto endpoint appears. It seems like the installer needs to find the arch and create the data dir ahead of time, or else systemd gets mad and goes into rate-limit hell.

wimdecorte · January 16, 2026, 6:23pm

Same issue for me on 4.15, using Ubuntu 24.04.3 LTS, AWS t4.xlarge EC2 instance.

Error in the system logs:
Jan 16 12:20:08 jaru systemd[1]: Failed to start ottofms-proofgeist-com.service - ottofms-service-proofgeist.
– Boot 7f2bc94259404d549bd99dde67143219 –
Jan 16 12:22:24 jaru systemd[1]: Started ottofms-proofgeist-com.service - ottofms-service-proofgeist.
Jan 16 12:22:24 jaru systemd[1]: ottofms-proofgeist-com.service: Main process exited, code=exited, status=4/NOPERMISSION
Jan 16 12:22:24 jaru systemd[1]: ottofms-proofgeist-com.service: Failed with result ‘exit-code’.
Jan 16 12:22:24 jaru systemd[1]: ottofms-proofgeist-com.service: Scheduled restart job, restart counter is at 1.
Jan 16 12:22:24 jaru systemd[1]: Started ottofms-proofgeist-com.service - ottofms-service-proofgeist.
Jan 16 12:22:25 jaru systemd[1]: ottofms-proofgeist-com.service: Main process exited, code=exited, status=4/NOPERMISSION
Jan 16 12:22:25 jaru systemd[1]: ottofms-proofgeist-com.service: Failed with result ‘exit-code’.
Jan 16 12:22:25 jaru systemd[1]: ottofms-proofgeist-com.service: Scheduled restart job, restart counter is at 2.
Jan 16 12:22:25 jaru systemd[1]: Started ottofms-proofgeist-com.service - ottofms-service-proofgeist.
Jan 16 12:22:25 jaru systemd[1]: ottofms-proofgeist-com.service: Main process exited, code=exited, status=4/NOPERMISSION
Jan 16 12:22:25 jaru systemd[1]: ottofms-proofgeist-com.service: Failed with result ‘exit-code’.
Jan 16 12:22:25 jaru systemd[1]: ottofms-proofgeist-com.service: Scheduled restart job, restart counter is at 3.
Jan 16 12:22:25 jaru systemd[1]: Started ottofms-proofgeist-com.service - ottofms-service-proofgeist.

I tried a few variations of what @barbar09 is implying but couldn’t get it to work.

jormond · January 20, 2026, 3:22pm

Also having the same issues on all of my Linux ARM deployments. Downgraded all versions back to OttoFMS 4.13.1.

Current OS and Instance types:

c7g.xlarge with Ubuntu 22.04.4 LTS / 22.04.5 LTS
m8g.xlarge with Ubuntu 22.04.5 LTS / 24.04 LTS
m8g.2xlarge with Ubuntu 22.04.5 LTS / 24.04 LTS

Works fine on macOS, Windows, and Ubuntu AMD deployments.

kduval · January 20, 2026, 6:56pm

Hey y’all,

OttoFMS 4.15.1 was just released that fixes this issue. Let me know if you continue having any issues on any Linux architectures when using the new version.

-Kyle

john_r · January 20, 2026, 7:42pm

Working for me on the server I was struggling with, Many thanks for getting to the root of this @kduval

GregZ · January 20, 2026, 10:47pm

I can confirm OttoFMS 4.15.1 is working fine on our ARM m7g.xlarge server.
Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-1044-aws aarch64)

jormond · February 5, 2026, 9:01am

Can confirm this installed and ran successfully on all the servers I am managing.