Reference

ATFS-NO-OWNER

Fully documented: why this happens, and how to fix it.

atfs refused to start because it has no owner. Every instance needs exactly one atproto identity, named in ATFS_OWNER_DID, before anything else can happen.

What triggered it

ATFS_OWNER_DID was empty when atfs started. atfs treats a missing owner as fatal rather than falling back to a default, because there is no safe default owner to fall back to.

Why this matters

The owner DID is the root of an atfs instance’s identity. Every other piece of its configuration — the upload allowlist, followed instances, the service DID — lives in an atproto record published under this DID, at at://{owner-did}/dev.atfs.server/{peer-id}. Without an owner, atfs has nowhere to look for that record, and no way to know who is even allowed to change it later.

Starting anyway, under some placeholder owner, would not be a safer fallback. It would produce an instance trusting nobody and fetching nothing, which fails just as completely as refusing to start, only less clearly.

Fix

Set ATFS_OWNER_DID to the DID or handle of the atproto account that should own this instance. See the settings reference for where this variable fits alongside atfs’s others, and Required settings for how to set it on your platform.

Note

Setting the owner does not by itself grant upload rights. Add the owner’s own DID to accounts on the dev.atfs.server record if it should also be able to upload to its own instance.

Common pitfalls

Confusing this code with ATFS-BAD-OWNER. ATFS-NO-OWNER means the variable is unset; ATFS-BAD-OWNER means it is set to something that fails to parse.
Setting ATFS_OWNER_DID in the wrong place — a shell export that does not reach the process, or a card partition that was never remounted after editing. See Required settings for the exact location per platform.

See Read the report for how to find this code in the first place, on whichever platform your instance runs.