Taildrop migration enables receiver without Tailscale operator permission on existing installs #8484

System details

Omarchy 4.0.1-1; Tailscale 1.102.3; existing Tailscale installation upgraded through migration 1785101000.sh

What's wrong?

After updating Omarchy, omarchy-tailscale-receive.service was enabled and started but could not receive files. It wrote the following error to the user journal every ten seconds:

getting WaitingFiles: Access denied: file access denied
Use 'sudo tailscale file get --wait --conflict=rename ~/Downloads/.omarchy-taildrop'.
To not require root, use 'sudo tailscale set --operator=$USER' once.

Cause

Migration 1785101000.sh enables the receiver for an existing Tailscale installation without ensuring that the desktop user is configured as the local Tailscale operator. By contrast, the current Tailscale installer runs sudo tailscale set --operator="$USER" before enabling the receiver.

The receiver treats every tailscale file get failure as transient, sleeps for ten seconds, and retries indefinitely. The systemd unit also has Restart=always, so a permanent authorization failure currently has no quiet terminal state.

Reproduction

1. Have Tailscale installed and connected without a local operator configured.
2. Update an existing Omarchy installation so migration 1785101000.sh runs.
3. Observe that the migration enables and starts omarchy-tailscale-receive.service.
4. Inspect journalctl --user -u omarchy-tailscale-receive.service and observe the repeating access-denied messages.

Expected

The upgrade should not leave a permanently unauthorized receiver enabled and repeatedly logging the same error. Possible behaviors include requesting operator authorization before enabling it, leaving it disabled until authorization is granted, or stopping on a permanent permission denial with one actionable notification.

Because migrations run per user while Tailscale's --operator setting names one Unix user, I did not want to assume which privilege behavior Omarchy intends. I am happy to open a PR once that behavior is clear.

Relevant source

• The current Tailscale installer configures the operator before enabling the receiver: https://github.com/basecamp/omarchy/blob/quattro/bin/omarchy-install-service-tailscale
• The migration enables the receiver but does not configure or check the operator: https://github.com/basecamp/omarchy/blob/quattro/migrations/1785101000.sh
• The receiver retries every failure indefinitely: https://github.com/basecamp/omarchy/blob/quattro/bin/omarchy-tailscale-receive
• The user unit restarts the receiver whenever it exits: https://github.com/basecamp/omarchy/blob/quattro/default/systemd/user/omarchy-tailscale-receive.service

Workaround

Users who do not need automatic Taildrop reception can stop the repeated failures without disabling Tailscale:

systemctl --user disable --now omarchy-tailscale-receive.service

Filed by GPT-5 via Codex.