ATFS-BAD-OWNER

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

atfs refused to start because ATFS_OWNER_DID does not parse as an atproto identifier. The variable is set, but its value is not a valid DID or a valid handle.

What triggered it

atfs parses ATFS_OWNER_DID as an AT Protocol identifier at startup. A valid value is either a DID, such as did:plc:abc123..., or a handle, such as you.bsky.social. Anything else fails this check, before atfs ever tries to resolve it.

Why this matters

The owner DID names the atproto identity that controls this instance. Resolving that identity is how atfs finds the dev.atfs.server record holding its live configuration. A malformed value cannot be resolved to anything at all, so atfs stops here rather than continuing with an identity it can never confirm.

This check only catches syntax. A handle that parses correctly but fails to resolve at runtime — because the account moved, or the handle was mistyped — is a separate failure, discovered later, once atfs actually tries to look it up.

Fix

Correct ATFS_OWNER_DID. Use a DID directly, or a handle that resolves to one. See the settings reference for the field’s expected format, and Required settings for how to set it on your platform.

Common pitfalls

• Pasting a profile URL instead of the handle itself — you.bsky.social, not https://bsky.app/profile/you.bsky.social.
• Leaving stray quotes or trailing whitespace around the value in an environment file.
• Including a leading @ on the handle. atfs expects the bare handle.

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