Skip to content

Desktop app: self-hosted SSH deploy can't reach remote Docker daemon ("Cannot reach Docker daemon: No such file") — works fine under Node, likely #10 regression #698

Description

@coddano

Summary

Deploying a Next.js project to a self-hosted server over SSH fails immediately at the Building stage from the desktop app, with:

Docker build failed: Cannot reach Docker daemon: No such file. Check that SSH credentials are correct, Docker is running on the server, and the SSH user can access the Docker daemon (in the `docker` group or root). The transport uses SSH socket forwarding where available and falls back to `docker system dial-stdio` over an exec channel otherwise.

This reproduced consistently (4/4 attempts) from the desktop app, and disappeared completely when the exact same project/server/deploy config was redeployed by running the app's own binary directly under Node instead (/Applications/Openship.app/Contents/MacOS/openship, bypassing the Electron/Bun wrapper) — the deploy then proceeded past this point (successful git clone, Docker build context packaging), confirming the transport and the target server are fine.

This looks like the same root cause as #10 (Bun's HTTP client not honoring the SSH-tunneled transport for this.docker.* / Docker-socket calls) resurfacing on the newer transport path described in the current error message (SSH socket forwarding + docker system dial-stdio fallback) — possibly a partial fix or regression, since #10 was closed as fixed.

Environment

  • Openship desktop app on macOS (Apple Silicon)
  • Target: freshly provisioned Ubuntu 22.04 server, added under Servers, auto-configured by the app (installed Docker 29.7.2 + Git + rsync successfully)
  • SSH: dedicated ed25519 key, openship user in the docker group (added manually after first failure, no change in outcome)
  • Framework: Next.js, runtime: sandboxed (Docker container), build strategy docker (remote Docker daemon via SSH)

What I verified server-side (all pass)

  • docker version / docker context ls over a plain SSH exec as the openship user: works
  • SSH stream-local port forwarding of /var/run/docker.sock from my machine to the server (ssh -L localsock:/var/run/docker.sock): works, socket created successfully
  • docker system dial-stdio over a plain SSH exec channel: no error returned
  • sshd -T: allowstreamlocalforwarding yes, disableforwarding no
  • Docker socket: srw-rw---- root:docker, group-accessible

Steps to reproduce

  1. Add a fresh Ubuntu server via SSH (key auth), let auto-configuration install Docker.
  2. Create a project from a GitHub repo (Next.js), deploy target = that server.
  3. Click Deploy from the desktop app. Fails at Building with the error above, in ~5-7s (before any clone/build output).
  4. Quit the desktop app, run /Applications/Openship.app/Contents/MacOS/openship directly (plain Node process, same local data dir), open the local dashboard it serves, redeploy the same project/config from there.
  5. This time it proceeds normally (git clone succeeds, build context packaged) — fails later at a separate, unrelated step (rsync key transfer, reported in a separate issue).

Suggested next step

Given #10's own suggested fix #1 ("run/ship openship-api under Node instead of Bun-compiling it") appears to fully resolve this when done manually, it seems like the Bun-compiled desktop binary may not actually be running the API under Node yet, or a Bun-specific code path was reintroduced after #10. Happy to provide more logs/environment details if useful.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions