# Enable podman.socket at install time (and one related USB rule)

From winvm, 2026-08-07 on ratio.

## 1. The ask: enable the rootless podman socket

    systemctl --user enable --now podman.socket

**What was wrong.** On ratio this was `disabled` / `inactive`, and
`$XDG_RUNTIME_DIR/podman/podman.sock` did not exist at all. Podman's CLI does
not need it, so nothing surfaces the gap until something speaks the REST API.

**Why it matters.** Every podman GUI and API client connects over that socket
rather than by shelling out. I installed Pods (`com.github.marhkb.Pods`,
flathub) to manage the Windows VM container, and without the socket it opens to
an empty window with no useful error — it looks like the app is broken or has no
containers, when in fact there is nothing listening. That is a bad first-run
experience and a hard one to diagnose from the symptom.

It is socket-activated, so enabling it costs nothing while idle: podman starts
on demand when a client connects, and `enable` brings the socket back on login
without a daemon sitting resident. This is the ordinary way to run the podman
API rootless.

**Verified after enabling:** socket present at
`/run/user/1000/podman/podman.sock`, the API answers
`/v5.0.0/libpod/containers/json`, and it reported the `WinVM` container.

**One Flatpak note worth recording**, because it looks like a problem and is
not. The Pods flatpak ships `xdg-run/podman:ro` in its filesystem permissions,
which reads as though a client could not connect. Tested from inside the
sandbox: the socket is visible, and both readable *and writable*, so the
read-only directory mount does not block the connection. No `flatpak override`
is needed.

**Client-side, not your problem but context:** Pods stores connections in
`~/.var/app/com.github.marhkb.Pods/config/pods/` and only writes that file after
the user adds a connection through the UI, so it can't be pre-seeded from an
install script without inventing the format. The one-time step is adding
`unix:///run/user/1000/podman/podman.sock` as a connection; a
`last-used-connection` gsetting makes it stick after that. So the *socket* is
the part worth automating, and the connection is not.

## 2. Related, same category — a udev rule for USB camera passthrough

Filing this alongside because it is the same class of one-time machine-level
setup and it will bite on velox the same way. Take it or leave it separately
from item 1.

`/etc/udev/rules.d/99-usb-passthrough-cameras.rules`:

    SUBSYSTEM=="usb", ATTR{idVendor}=="3564", ATTR{idProduct}=="ff02", GROUP="video", MODE="0660", TAG+="uaccess"
    SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="085e", GROUP="video", MODE="0660", TAG+="uaccess"

(3564:ff02 is the OBSBOT, 046d:085e the Logitech BRIO.)

**Why.** Streaming a USB camera into the VM runs `usbredirect`, which must open
the device read-write to claim it and detach the kernel drivers. The node
defaults to `crw-rw-r-- root:root`, so a normal user has read but no write and
the attach fails with a bare "Failed to open device!".

**The part worth writing down:** `TAG+="uaccess"` alone is NOT enough, though it
looks like the right answer and `udevadm test` confirms the tag is applied.
logind does not turn that tag into an ACL on a raw `/dev/bus/usb/*` node — it
manages ACLs for a narrower set of seat devices. The `GROUP`/`MODE` grant is
what actually works. The tag is kept because it is harmless and correct in
principle; it just isn't sufficient. I lost time on that, so it is recorded
rather than left to be rediscovered.

Both items are live on ratio and neither exists on velox.

## Correction (winvm, 2026-08-08)

The udev mechanism claim in section 2 above is wrong and stands corrected by
the sender: `TAG+="uaccess"` does apply to raw `SUBSYSTEM=="usb"` devices
(`70-uaccess.rules` tags them in several places). The real failure was rule
ordering — the ACL is applied by `73-seat-late.rules:16`, and a rule file
numbered `99-` adds the tag after that test has run. Every distro rule adding
the tag sorts at or below 70.

The `GROUP="video", MODE="0660"` grant remains the verified working fix.
Untested hypothesis from the sender: a rule file numbered below 73 would
likely make uaccess work on its own (a tighter grant than the group). The
installer task ships the rule numbered below 73 with both mechanisms and
leaves the uaccess-alone test for when the camera is attached.