[BUG] SSH Remote: "NO_HOME" error on QNAP NAS despite correct $HOME, /etc/passwd, and SFTP pwd

Status Open
Reported on v2.1.241
Maintainer reply None cached
Activity 0 comments · opened Aug 28, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Connecting Claude Desktop's SSH remote feature ("Code" tab) to a QNAP NAS
consistently fails with:

Couldn't inspect the remote machine: couldn't determine the remote home directory [NO_HOME]

This happens despite verifying that the home directory is correctly resolvable
through every standard mechanism:

  • ssh qnap "echo $HOME"/root
  • ssh qnap "pwd" (login shell) → /root
  • ssh qnap "getent passwd admin"admin:x:0:0:administrator:/root:/bin/sh
  • Manual sftp qnap session → pwd reports /root correctly
  • /etc/passwd home field matches $HOME exactly (verified after fixing an

earlier mismatch between /etc/passwd and actual $HOME)

I also fully reset local state (rm -rf ~/.claude on the remote, deleted and
re-added the SSH connection in the app) — the error persists.

Environment

  • QNAP NAS running QTS, BusyBox v1.24.1 userland
  • SSH server: OpenSSH_10.3 (remote software version, confirmed via ssh -vv)
  • User: admin, UID/GID 0:0 (QNAP's admin account shares root's UID)
  • SFTP subsystem confirmed working (Subsystem sftp /usr/libexec/sftp-server)
  • A separate Linux server (standard Debian-based, non-root user) connects

successfully with the same Claude Desktop version, same client machine

Suspected cause

Since every manual home-directory lookup method succeeds, but the app's
internal check still fails, I suspect the app may be using an SFTP protocol
extension (e.g. a home-directory style extended request) to determine the
home directory, rather than relying on the SSH session's own $HOME or a
plain getent passwd call over exec. If QNAP's /usr/libexec/sftp-server
build doesn't support that specific extension, or the UID-0/non-"root"-username
combination confuses that lookup, this would explain the mismatch between
manual tests succeeding and the app failing.

What Should Happen?

Connection succeeds, using /root (or whatever $HOME/getent passwd
reports) as the home directory — consistent with what a plain SSH/SFTP
session already resolves correctly.

Error Messages/Logs

## Relevant log excerpt (ssh.log)

    [SSH2Connection] ssh2: Inbound: Received USERAUTH_SUCCESS
    [SSH2Connection] Connected to admin@<redacted>:22
    [RemoteServerController] Connection failed (238ms, trigger: send_message, attempt 1): 
    Couldn't inspect the remote machine: couldn't determine the remote home directory [NO_HOME]

No SSH exec command or SFTP request appears between "Connected" and the 
failure, so I can't tell from the log alone what check is failing.

Steps to Reproduce

  1. Add a QNAP NAS as an SSH remote in Claude Desktop's "Code" tab

(admin@<qnap-ip>, key-based auth)

  1. Connection attempt fails with NO_HOME

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.241 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗