Description
nemoclaw <sandbox> share mount <remote-path> <local-path> does not differentiate between "sandbox is reachable but the remote path does not exist" and "sshfs failed for some other reason". When a user passes a typo'd or non-existent remote path (e.g. /sandbox/.openclaw/workspce/ instead of workspace), sshfs exits non-zero with no stderr output, and the CLI surfaces only:
The user has no signal that the source path is the problem — they cannot tell whether the sandbox is unreachable, the SFTP subsystem is missing, the local mount target is wrong, or simply that the remote path is a typo.
Reported by @SeseMueller in #3235 as a follow-up to the writable-fs error fix landing in #3235.
Reproduction
- Onboard a sandbox normally.
- Run with a sandbox path that does not exist:
$ nemoclaw my-assistant share mount /sandbox/does-not-exist /tmp/mnt
SSHFS mount failed.
(stderr from sshfs is empty in this case, so the CLI emits the bare failure line and nothing else.)
Expected
A clear, actionable error that names the missing path and points the user to verify it:
Sandbox path '/sandbox/does-not-exist' does not exist in sandbox 'my-assistant'.
Verify the path with: nemoclaw my-assistant connect, then ls /sandbox/does-not-exist
Suggested fix
Pre-flight check the remote path in the sandbox before invoking sshfs, mirroring the writable-mount-target pre-flight that landed in #3235. A single openshell sandbox exec <name> -- test -e <remote-path> covers the common case (path missing, parent missing, no permission to stat). If the exec fails, emit the structured error above instead of reaching sshfs at all.
This keeps the existing sshfs stderr-parsing intact for genuine SFTP-side failures, and short-circuits the silent-sshfs case.
Description
nemoclaw <sandbox> share mount <remote-path> <local-path>does not differentiate between "sandbox is reachable but the remote path does not exist" and "sshfs failed for some other reason". When a user passes a typo'd or non-existent remote path (e.g./sandbox/.openclaw/workspce/instead ofworkspace),sshfsexits non-zero with no stderr output, and the CLI surfaces only:The user has no signal that the source path is the problem — they cannot tell whether the sandbox is unreachable, the SFTP subsystem is missing, the local mount target is wrong, or simply that the remote path is a typo.
Reported by @SeseMueller in #3235 as a follow-up to the writable-fs error fix landing in #3235.
Reproduction
(stderr from sshfs is empty in this case, so the CLI emits the bare failure line and nothing else.)
Expected
A clear, actionable error that names the missing path and points the user to verify it:
Suggested fix
Pre-flight check the remote path in the sandbox before invoking
sshfs, mirroring the writable-mount-target pre-flight that landed in #3235. A singleopenshell sandbox exec <name> -- test -e <remote-path>covers the common case (path missing, parent missing, no permission to stat). If the exec fails, emit the structured error above instead of reachingsshfsat all.This keeps the existing sshfs stderr-parsing intact for genuine SFTP-side failures, and short-circuits the silent-sshfs case.