Aashish K C

Ten thousand steps, give or take four thousand

Mon, 21 Sep 2026 12:00:00 GMT

Set up Step Up App on a whim. Five of us in it now, one on Android, so it had to run on both.

I’d tell you ten thousand a day. My average is six, and the app shows it to four other people, which is the only reason I know.

One of them is past four hundred and twenty thousand steps for September with nine days still to go. That’s twenty thousand a day, every day. I’m not catching him.

Twelve containers on a laptop I'd stopped using

Sat, 12 Sep 2026 12:00:00 GMT

This is the first version of a home media server, and it’s shaped by its hardware.

The machine is a Dell Inspiron 7567 I bought in 2017 and hadn’t opened in three years. It wasn’t broken, it had just been superseded, and it had reached the stage where it either became something or went in a drawer permanently. So it got a fresh Debian install and this.

Nothing here was chosen for the job; it was chosen for the machine I happened to have. When it moves to hardware picked on purpose, some of these answers change, and I’ve tried to be clear about which ones.

What it does: media library and playback, audiobooks, a request interface for the people who use it, automated library management, and remote access. Twelve containers, one compose file, one bridge network.

The whole thing is at kcaashish/arrstack, with an .env.example and a Caddyfile.example in place of my real ones.

The decision everything else depends on

The single most consequential thing in the file is not a service. It’s how paths are mounted.

sonarr:
  volumes:
    - ${MEDIA_DIR}/appdata/sonarr:/config
    - ${MEDIA_DIR}/library:/data

One mount, not two. I ran it as two for weeks, and it was wrong in a way that looks entirely correct.

This matters because of how Sonarr and Radarr import files. Given a finished download and a library to file it into, they hardlink: the file gets a second name in the library, occupies no additional space, and keeps seeding under its original one. Failing that they copy, and every file exists twice on disk. On a laptop with one disk, that’s the difference between the thing being viable and not.

The condition is usually stated as “both paths on the same filesystem.” That’s necessary and it isn’t sufficient. What the kernel compares is the mount:

error = -EXDEV;
if (old_path.mnt != new_path.mnt)
    goto out_dput;

do_linkat is looking at vfsmount pointers, not device numbers. Every -v line in a compose file creates its own bind mount, so two volume lines are two mounts regardless of where they came from on the host or what they’re called inside the container.

Which is exactly what my first version did:

# what I had, and what most guides show
- ${MEDIA_DIR}/torrents:/data/torrents
- ${MEDIA_DIR}/media/tv:/data/media/tv

Both under /data. Both from one directory on the host. Both on one ext4 volume, which the container will confirm if you ask it:

$ docker exec sonarr mount | grep /data
/dev/mapper/inspiring--dell--007--vg-root on /data/torrents type ext4 (rw,relatime,errors=remount-ro)
/dev/mapper/inspiring--dell--007--vg-root on /data/media/tv type ext4 (rw,relatime,errors=remount-ro)

$ docker exec sonarr sh -c 'touch /data/torrents/.hltest &&
    ln /data/torrents/.hltest /data/media/tv/.hltest'
ln: failed to create hard link '/data/media/tv/.hltest' => '/data/torrents/.hltest': Cross-device link

Same volume, same filesystem, refused. Every import had been quietly copying, and nothing anywhere said so. You find out from df.

The fix is one directory level. appdata holds each service’s configuration and shouldn’t be visible to anything but its own container, so it can’t sit inside the tree that gets mounted. Everything that does get mounted moves under library/, which is then mounted once:

The container-side paths didn’t change, so nothing inside the applications needed reconfiguring. It was a directory move and two edited lines.

The services that don’t hardlink take narrower mounts. qBittorrent only needs the download directory, Jellyfin only needs the media directory, and Bazarr only needs to find the files Sonarr tells it about:

bazarr:
  volumes:
    - ${MEDIA_DIR}/library/media:/data/media

That last one is a different requirement wearing similar clothes. Bazarr isn’t linking anything, so mount count is irrelevant to it; it just has to agree that /data/media/tv names the same directory Sonarr meant when it reported a path. Container path strings have to match. Treating that as the same rule as the hardlink one is how I talked myself into the first version.

Updates: pinned tags, and the auto-updater switched off

Every image is pinned to an exact version.

image: linuxserver/sonarr:4.0.19
image: caddy:2.11.4
image: ghcr.io/seerr-team/seerr:v3.4.1

Watchtower, which would pull and restart containers automatically, is in the file and commented out. In its place:

wud:
  image: ghcr.io/getwud/wud:8.4.0
  environment:
    - WUD_WATCHER_LOCAL_CRON=0 12 * * *
    - WUD_TRIGGER_DISCORD_MYDISCORD_URL=${WUD_DISCORD_WEBHOOK_URL}

What’s Up Docker checks once a day and posts to Discord when something has a newer version. It doesn’t touch anything. I read the release notes and bump the tag by hand.

The reasoning is about failure timing. With :latest and an auto-updater, a breaking change arrives at 4am while nobody is watching, and the first symptom is someone telling you playback is broken. With pinned tags, the same breaking change arrives when I choose, with the release notes open, and rolling back is editing one line.

The filtering is done with a label on each service:

labels:
  - "wud.tag.include=^\\d+\\.\\d+\\.\\d+$"

That regex restricts notifications to plain semver tags. Without it, WUD reports every latest, nightly, develop and 2.11 tag as an available update and the notifications become noise you stop reading. Services that prefix their tags with v get ^v\\d+\\.\\d+\\.\\d+$ instead.

What Caddy fronts

Caddy fronts the three services that other people actually use:

http://jf.example.com {
    reverse_proxy jellyfin:8096
}

http://rq.example.com {
    reverse_proxy seerr:5055
}

http://abs.example.com {
    reverse_proxy audiobookshelf:80
}

Note the explicit http://. Caddy provisions certificates automatically by default, and naming the scheme turns that off. For hostnames that only resolve on the LAN there’s no public challenge to satisfy, so this is deliberate rather than an omission. Proxying by service name works because they share media-network and Docker’s embedded DNS resolves container names.

The approach I built first and then deleted

Before the tunnel, the plan was to give the internal hostnames real certificates. That meant a custom Caddy build:

FROM caddy:2.11.4-builder-alpine AS builder
RUN xcaddy build --with github.com/caddy-dns/cloudflare

FROM caddy:2.11.4-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

The stock Caddy image ships with no DNS provider modules, so getting one means compiling your own binary with xcaddy. Compose built it inline and passed a scoped Cloudflare token:

caddy:
  build:
    context: .
    dockerfile: inline-caddy.Dockerfile
  environment:
    CLOUDFLARE_API_TOKEN: ${CLOUDFLARE_API_TOKEN}

The reason for all of it is the ACME challenge type. The default, HTTP-01, requires Let’s Encrypt to reach port 80 on your server from the public internet, which internal-only hostnames by definition can’t satisfy. DNS-01 proves control by writing a TXT record instead, so it works for services that are never publicly reachable, and the Cloudflare DNS module is what lets Caddy write that record.

It worked. Then the remote access problem killed it.

Why the tunnel, specifically

Certificates were never the hard part. Reaching the machine was.

Residential connections here don’t come with a static IP and you can’t buy one. The usual answer is dynamic DNS, which handles an address that changes but assumes there’s a publicly routable address to point at in the first place. When the connection doesn’t give you one, port forwarding has nothing to forward to and no amount of DNS configuration helps.

A Cloudflare tunnel sidesteps the whole question by reversing the direction:

cloudflared:
  command: tunnel --no-autoupdate run
  environment:
    TUNNEL_TOKEN: ${CLOUDFLARE_TUNNEL_TOKEN}

The daemon dials out to Cloudflare and holds the connection open. Traffic arrives back down a link the server established itself. Nothing is forwarded, the router is untouched, and there’s no inbound port to expose or protect.

Which then made the custom Caddy build pointless. TLS now terminates at Cloudflare’s edge, so nothing on the box needs a certificate, and Caddy drops back to the stock image serving plain http:// internally. The CLOUDFLARE_API_TOKEN line and the inline-caddy.Dockerfile reference are still sitting commented out in my compose file.

That’s the shape of the decision worth recording. The first approach wasn’t wrong and it didn’t fail. Solving a different problem properly made it unnecessary, and the work I threw away was the work that showed me which problem actually mattered.

Three ways in, on purpose

The machine has no desktop. Nothing on it was ever reachable at localhost, the setup wizards included, so remote access wasn’t a feature to add once it was working. It was a precondition for configuring anything at all.

That’s what Tailscale does here, and it’s the one piece of this that isn’t in the compose file at all. It installs on the host rather than as a container, joins the machine to a WireGuard mesh, and gives it an address that works from my Mac whether I’m on the same network or not. Sonarr, Radarr, Prowlarr, qBittorrent and the rest are administered entirely over that, including their first run.

The two remote paths aren’t redundant, they’re aimed at different people. The tunnel exists because the people who use Jellyfin and Seerr can’t reasonably be asked to join a tailnet. Tailscale exists because the alternative is putting admin panels on the public internet in order to configure them. The LAN is just what’s left when I’m sitting next to the thing.

Three things that cost me time

The two Jellyfin images disagree about /config. LinuxServer keeps the XML configuration at the top level of it; the official image expects that one directory further down and treats /config itself as data. Jellyfin 10.11 drops a marker file in the directories it owns and refuses to start when it finds the wrong one, so swapping the image against a directory the other one had already initialised produces this and then a crash loop:

Unhandled exception. System.InvalidOperationException: Expected to find only
.jellyfin-data but found marker for /config/.jellyfin-config.

A fresh /config works with either image, which is why it reads as though the swap broke something that used to work. The rule I’d actually give myself is not “use the linuxserver image.” It’s that image lineage can’t change under a /config that has already been claimed.

Hardware transcoding needs the device passed through.

jellyfin:
  devices:
    - /dev/dri:/dev/dri

This is what makes an old laptop workable at all. Without it every transcode is software, the CPU pins, and the fans announce it from another room. With the integrated GPU exposed, transcodes are cheap. It’s one line, and without it this machine wouldn’t be up to the job.

Two different ways to not run as root. The linuxserver images take PUID and PGID as environment variables and drop privileges in their own init. Audiobookshelf isn’t a linuxserver image, so the same variables do nothing and it needs Compose’s own directive:

audiobookshelf:
  user: "${PUID}:${PGID}"

Get this wrong and files land owned by root, which you notice weeks later when something can’t write.

What’s wrong with it

Being honest about a first pass is most of its value.

One disk, no redundancy, no backups. The appdata directory holds every service’s configuration and database and is backed up nowhere. This is the most embarrassing item on the list and the cheapest to fix.

Media lives under /home. Which is what makes a single mount possible, and also means the library shares a filesystem with the operating system. Fine at this size, wrong as a permanent arrangement. On the next box, storage gets its own filesystem and the layout gets recreated there.

depends_on doesn’t mean ready. It orders startup and nothing more. Compose starts Sonarr the moment the qBittorrent container exists, not when it’s accepting connections, so a cold boot produces a spread of connection errors that resolve themselves. Health checks with condition: service_healthy would fix it properly.

It’s a nine-year-old laptop. Lid behaviour, thermals, and a 2017 battery now serving as an accidental UPS. It works, but nothing about the chassis was designed to run continuously, and the failure I should plan for is hardware rather than software.

WUD holds the Docker socket. Read-only would be enough for what it does, and it currently has more than it needs.

No monitoring. I know something broke when someone tells me. There’s no metrics, no uptime check, no alerting beyond update notices.

What the next version looks like

Real hardware, which turns most of the list above from a constraint into a design decision.

The path layout stays exactly as it is. That’s the one decision here I’m confident survives the hardware.

A homelab is a very expensive way to learn that DNS works

Sat, 12 Sep 2026 11:59:00 GMT

There is a particular kind of satisfaction in making an old computer do something useful.

Then you add Caddy. Cloudflare. Tailscale. Jellyfin. Monitoring. Containers. Another container to manage the containers.

Eventually you’re spending an evening fixing a problem that wouldn’t exist if you had just paid for the service.

That’s part of the point.

The app that would not let go

Sat, 29 Aug 2026 12:00:00 GMT

An older relative came to me with a phone that had stopped behaving. The battery was draining in hours. Google Play Protect had flagged something and claimed to have dealt with it. But the app was still there in Settings, and it would not come off.

Every time he opened the uninstall screen, the screen closed itself. He tried a factory reset. The reset screen closed itself too.

By the time it reached me, he had been living with it for six days. He had installed it after seeing an advertisement on TikTok for an app called Mox, which promised free IPTV, films and series. The link took him outside the Play Store to an APK he installed by hand.

This is what it took to find it, why the obvious approach failed, and why the phone kept closing its own settings screens.

The first thing I tried, and why it found nothing

The app was called Mox, so:

adb shell pm list packages | grep -i mox

Nothing.

That result is the whole lesson of this case, so it’s worth being precise about why. The name you see in Settings is the app’s label, a human-readable string stored in the APK’s resources, which the developer can set to anything. The package name is a separate identifier, and nothing requires the two to resemble each other.

Here, the label said Mox. The package name was com.nzr.truove.

Searching by name cannot find an app that does not want to be found. I widened the net anyway, in case something turned up in a component name or a file path:

adb shell pm list packages -d      # disabled packages
adb shell pm list packages -u      # includes uninstalled packages with retained data
adb shell pm list packages -f      # includes the APK path
adb shell dumpsys package | grep -i mox

Still nothing matching “mox”. The -u list did contain com.nzr.truove, but at that point it was one unremarkable string among three hundred. I had no reason to look at it twice.

I also checked for a hidden work profile, which is a common place for things to sit out of sight:

adb shell pm list users

One user. Nothing hiding there either.

Name-based search was exhausted.

The pivot: search by capability instead

If you cannot find an app by what it is called, find it by what it can do.

This turns out to be a much better approach in general, because the set of permissions that make an app genuinely dangerous is small, and Android will list every holder of them on request. Three commands cover it:

adb shell settings get secure enabled_accessibility_services
adb shell settings get secure enabled_notification_listeners
adb shell dumpsys device_policy | head -40

The first one ended the search:

com.openai.chatgpt/com.openai.feature.conversations.screencontext.ConversationScreenAccessibilityService
:com.nzr.truove/com.nzr.truove.muuozzscovxd

Two entries. The first belongs to a known app and has a descriptive class name. The second is an unrecognised package whose service class is muuozzscovxd, a random consonant string.

Real developers name a service something like ScreenReaderService, because they have to maintain it. Randomised class names exist to defeat signature-based scanning. An unknown package holding accessibility rights under an obfuscated name is not an ambiguous finding.

Why the phone kept closing its own screens

An enabled accessibility service is the most powerful thing a non-system app can hold on Android. It is designed for screen readers and switch access, so it grants two capabilities together:

read the entire contents of every screen, including text typed into password fields
generate synthetic taps, swipes and gestures

The second half is what my relative had been fighting for six days. The app could see which screen was open. When that screen was its own uninstall page, or the factory reset page, it pressed Back, a real input event, indistinguishable from a finger.

I expected the wrong answer

The usual cause of an un-removable Android app is device administrator rights, which let an app formally block its own uninstall. So I checked:

adb shell dumpsys device_policy | head -40

No device administrators registered. It had no formal protection at all. It was simply watching the screen and tapping Back faster than a person could finish the flow.

That distinction matters practically. ADB commands go to the package manager directly. There is no screen for the app to detect and no button for it to press, so it cannot interfere. If you are stuck using the phone’s own UI, the equivalent move is to revoke the accessibility permission first. That removes the app’s hands before you try to remove the app.

The same dump corroborated the finding independently:

accessibility services: 2 apps
  0: com.openai.chatgpt
  1: com.nzr.truove

Notification access, meanwhile, was clean. Truecaller, Samsung Routines, the launcher, nothing unexpected. Useful negative evidence: whatever this was, it was not reading notifications.

What it actually had

adb shell dumpsys package com.nzr.truove \
  | grep -iE "versionName|firstInstallTime|installerPackageName|requested permissions" -A 25

The record was unambiguous.

installerPackageName was absent and packageSource was 0, confirming a sideload rather than a Play Store install. The version string was 2.184.44 suupenavuvubgfpxk, with a random token appended to a plausible-looking version number. It declared around twenty-five custom permissions under a com.gbu.efgypmb namespace that corresponds to no real package. Anti-analysis noise, nothing more.

Then the runtime grants:

android.permission.READ_SMS:     granted=true
android.permission.CAMERA:       granted=true
android.permission.RECORD_AUDIO: granted=true

READ_SMS is the line that changed the nature of the problem.

Screen reading gives you what someone types into a login form. READ_SMS gives you the one-time passcode sent to confirm it. Held simultaneously, they collapse two-factor authentication into one factor, because both factors arrive at the same compromised device. Every banking app on that phone had been operating inside that window.

firstInstallTime gave the window’s start: 23 August, 13:24. That single field turned out to be the most valuable thing in the whole dump, because it is what a bank’s fraud team needs in order to know which transactions to review.

Checking whether it came alone

Malware often installs companions, so before removing anything I checked whether the timeline had other entries:

adb shell pm path com.nzr.truove
adb shell pm list packages | grep -i "gbu\|efgypmb"

The APK sat under /data/app/, which is the ordinary third-party area. That was good news: a package under /system/ or /product/ would have been a privileged preinstall and a much worse problem. The phantom permission namespace matched no installed package.

I then checked install dates on every other unexplained package on the device. One was timestamped 2008, the factory image date, so a vendor preinstall. The rest were from ten months earlier. Nothing else appeared on 23 August. Single package, single incident.

Removal, and confirming it

adb pull /data/app/~~.../base.apk ~/evidence.apk     # keep a copy first
adb shell pm disable-user --user 0 com.nzr.truove    # contain, reversible
adb shell pm uninstall --user 0 com.nzr.truove       # remove app and data

disable-user switches an app off immediately without deleting it, which is useful when you want the threat neutralised now but the evidence intact.

Verification is where it is easy to fool yourself:

adb shell pm list packages -u | grep nzr
adb shell settings get secure enabled_accessibility_services
adb shell find /sdcard -iname "*.apk"

The -u flag is essential. A plain pm list packages will report clean even when the package was uninstalled with its data directory deliberately retained. Without -u you cannot tell “removed” from “removed, but it kept everything”.

All three came back clean. The accessibility list was down to the one legitimate entry, and the original APK was no longer sitting in Downloads waiting to be run again.

What I would do first next time

Knowing the answer, two commands would have found this in under a minute.

Audit the privileged grants before enumerating anything. The three settings and dumpsys reads above produce a list short enough to check by eye, and anything hostile enough to matter is almost certainly in it. I spent most of my time enumerating packages, which was the wrong end of the problem.

List everything that did not come from the Play Store:

adb shell pm list packages -i -3 | grep -v "installer=com.android.vending"

On an ordinary consumer phone this should be close to empty. A sideloaded app nobody remembers installing is worth a hard look.

The part that isn’t technical

Removing the app does not undo the exposure. For six days, credentials and SMS passcodes had both been readable on that device, and no amount of correct ADB work changes that. The actual remediation happened elsewhere: credentials reset from a different, clean device, the bank notified with the exposure window so they could review activity against it, and passcodes rotated on every account that had been opened on the phone during those six days.

The triage tells you what happened and when. It is the beginning of the response, not the end of it.

There is also a design observation buried in this, which I keep turning over. Accessibility services exist for a genuinely good reason. They are how blind users operate a phone at all. The capability cannot be removed without removing that. But the same grant that lets a screen reader describe an interface lets hostile software operate it, and a person tapping through a consent dialog on a phone they got from a TikTok advertisement is not equipped to tell those apart. The permission model is technically sound and, for the person actually holding the phone, close to useless.

A fast website is mostly a website that doesn't do much

Wed, 19 Aug 2026 12:00:00 GMT

I’ve spent an unreasonable amount of time looking at why some personal websites feel instantaneous.

The answer is less exotic than I expected.

Don’t ship what you don’t need. Don’t make the browser assemble what could have been a document. Don’t add JavaScript just because the framework makes it easy.

There is something satisfying about a website that arrives almost completely finished.

Debian doesn't install sudo if you set a root password

Wed, 15 Jul 2026 12:00:00 GMT

sudo: command not found on a fresh install isn’t a broken image. If you set a root password during setup, Debian assumes you’ll use su and skips the package entirely. Leave that field blank and it installs sudo and adds you to the group for you.

su -
apt update && apt install sudo -y
usermod -aG sudo your_username
exit

Log out fully and back in. Group membership is read at login, so a new shell in the same session still won’t see it. Once you’re back in, sudo whoami prints root.

This surprised me because I’d assumed sudo was a base package everywhere. It isn’t. It’s a package Debian installs conditionally, based on an answer you gave several minutes earlier and have already forgotten.

Read the standard library before reaching for a package

Wed, 24 Jun 2026 12:00:00 GMT

I spent an afternoon evaluating rate limiter packages before someone pointed at golang.org/x/time/rate, which does exactly what I needed and is about two hundred lines I could actually read end to end.

This keeps happening. Go’s standard library and the x/ repos cover more than I expect, and the code is short enough to read rather than trust. Now the first step is a search there, and only then in the wider ecosystem.

Write the migration so it can run twice

Wed, 03 Jun 2026 12:00:00 GMT

Deploys get retried. Pods restart mid-migration. Someone runs the command again because they weren’t sure it took.

IF NOT EXISTS on creates, IF EXISTS on drops, and a backfill written as an idempotent update rather than an insert. It costs nothing to write it this way the first time and saves an incident later.

The exception is anything destructive. Those I want to fail loudly on a second run, because a DROP COLUMN that quietly succeeds twice means I’ve lost track of what state the database is in.

Reading a book is not the same as finishing one

Thu, 16 Apr 2026 12:00:00 GMT

I’ve started thinking less about how many books I finish and more about whether a book changes what I notice.

A book can sit half-read for months and still give you an idea you carry around for years.

Finishing is a useful metric for Goodreads.

It isn’t necessarily a useful metric for reading.

The first kilometre is supposed to feel bad

Sun, 14 Dec 2025 12:00:00 GMT

Two years of assuming a rough opening kilometre meant a rough run. It doesn’t. It means I haven’t warmed up yet, which is the expected state of a body that was asleep twenty minutes ago.

Starting deliberately slower than feels right makes kilometres three through eight better than they’ve ever been. The same lesson keeps showing up at work, where the instinct to start fast is also usually wrong.

The goroutine leak was a missing cancel

Thu, 30 Oct 2025 12:00:00 GMT

Memory climbing slowly over days, nothing obvious in the heap profile. It was in the goroutine profile instead: thousands of them parked on a channel receive that would never fire.

ctx, cancel := context.WithTimeout(parent, 2*time.Second)
defer cancel() // this line was the whole bug

WithTimeout allocates a timer and registers the child with its parent. Without cancel(), neither is released until the timeout fires — and if the parent outlives the process, effectively never. go vet catches the obvious cases; this one was behind a helper function, so it didn’t.

Paid for the year so I'd stop deciding

Thu, 27 Feb 2025 12:00:00 GMT

Bought twelve months of a training-plan app in one payment, which is not how I usually buy software. Monthly is the flexible option, and flexible is exactly the problem; it leaves a small decision sitting there every thirty days.

Prepaying removes it. There’s no renewal to reconsider in April when it’s raining and I’ve already skipped a week. The money is gone, and the only thing left to decide is whether to run.

Priced against one evening out, a year of structured training isn’t a close call. Two runs in, which is far too early to say anything about the plans themselves.

Alias the host, not the key

Thu, 05 Oct 2023 12:00:00 GMT

Two GitHub accounts on one machine is the usual reason people go looking for this, and the usual answers are bad: per-repository core.sshCommand overrides, or a script that swaps id_ed25519 in and out of the agent.

Neither is necessary. ~/.ssh/config lets you invent a hostname that only exists on your machine and bind a key to it:

Host personal.github.com
  HostName github.com
  AddKeysToAgent yes
  UseKeychain yes
  User git
  IdentityFile ~/.ssh/id_ed25519

Host work.github.com
  HostName github.com
  AddKeysToAgent yes
  UseKeychain yes
  User git
  IdentityFile ~/.ssh/id_ed25519_work

Host is a label that means nothing outside this file. HostName is where the connection actually goes. So both entries reach github.com, and which key gets offered depends only on which fiction you typed.

Then the remote URL carries the choice:

git clone git@personal.github.com:username/repo.git

The key selection now lives in the URL, which lives in .git/config, which travels with the clone. Nothing to remember and nothing to switch.

On macOS, UseKeychain yes stores the passphrase in the keychain and AddKeysToAgent yes loads the key on first use, so you type the passphrase once ever rather than once per reboot.

When it doesn’t work, one flag tells you why:

ssh -vT git@personal.github.com

The verbose output names the config entry it matched and the key it offered. Almost every failure here is one of two things: the URL still points at plain github.com, or you added a second key to an account that already has the first one. GitHub rejects a key that’s registered to a different account with a message about repository access, which sends people looking at permissions when the problem is the key.

One SSH key, one GitHub account

Thu, 05 Oct 2023 11:59:00 GMT

Pushed to a repository I definitely had access to and was told I didn’t. The key was the problem: GitHub only lets a key be registered once across all accounts, and mine was still attached to the other one.

Nothing in the error says that. You get a message about the repository, so you go and check the repository, and everything there is fine.

ssh -T git@github.com

The reply names the account it just authenticated you as. When that’s the wrong name, stop looking at permissions.

One Mac, two users, one Homebrew

Tue, 19 Sep 2023 12:00:00 GMT

At some point you end up wanting two accounts on one Mac. Maybe the work you’re doing should live somewhere your personal browser sessions and SSH keys don’t. Maybe your employer wants a managed account and you’d rather not hand over the whole machine. Whatever the reason, the request is modest: one laptop, two logins, a clean line between them.

macOS handles the first ninety percent of that well. Separate home directories, separate keychains, separate browser profiles, fast user switching. Then you open a terminal in the new account and type brew, and nothing happens.

What follows is everything that broke, and why each thing broke, because the reasons turn out to be more interesting than the fixes.

The core problem: two different ideas of ownership

macOS is built around per-user isolation. Almost everything meaningful lives under ~/Library, and a second account genuinely starts from nothing.

Homebrew is built around a single shared prefix. On Apple Silicon that’s /opt/homebrew, and it is owned by whichever user installed it. Not by root, not by a group, but by a person.

Those two models are individually sensible and jointly awkward. Your second account can see /opt/homebrew because it’s world-readable, but it can’t write to it, and Homebrew wants to write constantly: updating formulae, linking binaries, managing its own git repository.

There are three ways out and only one of them is good.

Install a second Homebrew. Works, and it’s the option Homebrew’s own documentation is most comfortable with. But you now have two package databases, two update cycles, and several gigabytes of duplicated Xcode-adjacent dependencies on a laptop SSD. You will also, eventually, be confused about which one you’re talking to.

Change ownership to a shared group. Tempting, and it appears in a lot of forum answers. It’s fragile. Homebrew resets permissions during some operations, and you end up re-running chown after upgrades and wondering why things broke.

Run brew as the user who owns it. This is the one I settled on:

alias brew='sudo -Hiu akc brew'

Where akc is my personal account, the one that installed Homebrew. The flags matter:

-u akc runs as that user
-i starts a login shell, so Homebrew gets the environment it expects rather than an inherited one from the calling account
-H sets $HOME to the target user’s home, which is what stops Homebrew writing its cache and logs into the wrong place

The result is that installing a package from the work account installs it into the personal account’s Homebrew, and both accounts use it.

That last part is the piece worth understanding. Homebrew’s management needs write access, but the things it installs land in /opt/homebrew/bin, which is readable and executable by everyone on the machine. So the second account doesn’t need Homebrew at all in order to use what Homebrew installed. It just needs the path:

# ~/.zprofile
export PATH="$PATH:/opt/homebrew/bin"

.zprofile rather than .zshrc, because this is environment setup that should happen once at login rather than on every interactive shell.

Docker, which fails differently

Docker Desktop breaks for a related but distinct reason, and the failure looks identical from the terminal: docker: command not found.

The application itself is in /Applications and every account can launch it. But Docker Desktop installs its CLI tools (docker, docker-compose, docker-buildx) into the user’s home directory at ~/.docker/bin, and then symlinks or path-injects them per account. The second user gets the app and none of the commands.

# ~/.zprofile
export PATH="$PATH:$HOME/.docker/bin"

Launch Docker Desktop once from the new account first, so it populates that directory. There’s a long-running thread on docker/for-mac about multi-user behaviour if you want the full history.

Dotfiles: symlink, don’t copy

The obvious move is to copy your config across. Don’t. You’ll edit one, forget the other, and spend a month wondering why your Neovim keybindings differ depending on which account you’re in.

Symlink instead, so there’s one source of truth. There are two places that source of truth can live, and the difference matters more than it first appears.

Option one: keep the repo in one user’s home and link across.

cd ~/.config
ln -s /Users/akc/.dotfiles/nvim/.config/nvim/ nvim
ln -s /Users/akc/.dotfiles/lazygit/.config/lazygit/ lazygit

This works, and it’s the smaller change if your dotfiles already live in ~. One caveat to check on your own machine: macOS makes a home directory itself readable by other users but locks down several subdirectories inside it. A .dotfiles repository sitting directly in ~ is reachable; the same repo inside ~/Documents is not. If your symlinks resolve but the target won’t open, that’s the reason, and moving the repo up a level fixes it.

Option two: move the repo to /Users/Shared and link from both accounts.

mv ~/.dotfiles /Users/Shared/dotfiles

cd ~/.config
ln -s /Users/Shared/dotfiles/nvim/.config/nvim/ nvim
ln -s /Users/Shared/dotfiles/lazygit/.config/lazygit/ lazygit

/Users/Shared exists on every Mac for exactly this: a directory outside anyone’s home that all local accounts can read and write. This is what I ran for a long time, and it’s the better default.

Two reasons. The permissions problem disappears, because you’re no longer reaching into another account’s home directory and hoping macOS lets you. And it removes the asymmetry. With option one there’s a primary account that owns the config and a secondary one that borrows it, so deleting or renaming that account takes your dotfiles with it. In /Users/Shared neither account is privileged, and both are just clients of the same repository.

The tradeoff is that /Users/Shared is writable by every local account, so anything with a credential in it doesn’t belong there. Config yes, secrets no. That’s the rule anywhere, but it’s easier to violate by accident when the directory is this convenient.

Shell config is the exception. .zshrc, .zprofile and .zshenv genuinely differ between the accounts, with different aliases, different paths and different work-specific variables, so those get copied once rather than linked, and then diverge on purpose.

Moving files between your own two accounts

This is more annoying than it should be, because from the filesystem’s point of view you are two unrelated people.

Every macOS account has a ~/Public folder that is readable by other users on the machine, with a Drop Box inside it that is write-only from outside. That’s the intended channel, and it’s what I use for the one-time transfers: shell config, zsh plugin directories (zsh-autosuggestions, fast-syntax-highlighting), fonts.

Fonts are worth a note of their own. Installing to ~/Library/Fonts makes them available to one account only; /Library/Fonts makes them available to everyone. If you’re using a patched Nerd Font in your terminal, install it system-wide once and stop thinking about it.

For iTerm2, don’t hand-recreate your setup. Export the profile as JSON from the original account, drop it in ~/Public, and import it in the new one.

What the setup actually looks like

After all of it, the division is:

Shared

Homebrew and everything it installs
System fonts
Docker Desktop, the application
A dotfiles repo in /Users/Shared, symlinked into ~/.config from both

Separate

Shell configuration
SSH keys
Git identity
Keychains and browser profiles
Application state
Docker's per-user CLI and contexts

Which is roughly the right line. The things that are expensive to duplicate are shared; the things that carry identity or credentials are not.

The thing I keep thinking about

None of these are bugs. Homebrew’s single-prefix design is a deliberate trade that makes the common case fast and simple, and macOS’s per-user isolation is correct. Docker Desktop putting its CLI in the user’s home is defensible too.

But every one of them encodes an assumption that a laptop belongs to one person, and that assumption is doing a lot of quiet work. The moment you need two accounts, whether for a job, a contract, or a boundary you want to keep, you’re not fighting a limitation so much as discovering a premise nobody wrote down.

There’s a version of this in most software I work on. The default configuration is the shape of someone’s assumption about who you are, and you only find out what that assumption was when you stop matching it.