Diagnose a remote connection failure from the host outward: target identity, network reachability, SSH availability, authentication, privileges and storage access. Keep those stages separate. A working shared folder does not prove that the application has the root-level SSH access required by the approved NAS/Linux workflow.
Confirm the intended host and route
Check the host address against the administrator’s record, including any approved port and network route. Determine whether the target is powered on and accessible through that route. A changed address, different subnet or unavailable permitted VPN can prevent a connection before credentials are relevant.
Do not repeatedly change unrelated settings to see what works. Record the exact stage and message. Coordinate with the authorized administrator rather than opening management services publicly or disabling network controls as a general fix.
Separate SSH availability from authentication
Have the administrator confirm that the target’s SSH service is enabled and reachable by the intended client. A NAS web page or SMB share can work while SSH is unavailable. Their success does not identify a password problem in the recovery application.
When authentication fails, verify the authorized account and supported access method. Do not paste credentials into a shared transcript or keep retrying a guessed password. Account policy, access restrictions and the connection method need their own check.
Confirm the required privileges
XRecovery’s documented NAS/Linux route requires root access. A user who can browse a share may not have permission to read the underlying storage. Ask the administrator to establish the permitted root-access method supported by the application; do not assume that every NAS exposes identical login controls.
Avoid treating an authorization failure as a reason to run file-system repair or format a volume. Those operations address a different layer and may change the source without fixing the connection.
Inspect storage only after the session works
If sign-in succeeds but the intended source is absent, compare the target’s actual volume and array configuration with the application listing. Check readable media, encryption requirements and file-system support. Keep the original configuration unchanged; do not initialize or rebuild the array to make a missing volume appear.
Documented Ext4/Btrfs reading uses remote scanning or quick scanning. A successful connection does not certify every storage feature or damaged layout. For unstable devices or incomplete arrays, decide whether continued reading is appropriate before another scan.
Match the symptom to the next check
| What you observe | Check next | What to record |
|---|---|---|
| The connection does not reach the host | Ask the administrator to verify the host, permitted network route and SSH service. | Address used, failure stage and time; omit secrets. |
| The host is reachable but sign-in fails | Confirm the authorized account, credentials and permitted root access method. | Authentication stage and the exact non-secret message. |
| SSH is reachable but the required root privileges are unavailable | Ask the administrator to confirm the authorized access method supported by the application. | The non-secret privilege error and connection stage. |
| Sign-in succeeds but the volume is absent | Compare the listed storage with the NAS volume, file system and array record. | Expected volume and what is displayed. |
| The volume appears but the desired file is absent | Recheck the source, scan route, path and time range before selecting another target. | Source identity, scan choice, file path and observed results. |
For example, if an SMB share opens but SSH sign-in fails, investigate SSH authentication and root access with the administrator; rescan or file-system repair cannot fix that login stage.
Keep useful diagnostics without secrets
Record the application build, target system, failure time, stage, exact non-secret message and whether any storage was read or output saved. Remove passwords, tokens, private file content and unnecessary identifiers before sharing logs. Keep the complete authorized record privately when needed for diagnosis.
After correcting a defined condition, retry that connection stage rather than restarting unrelated recovery work. Once the connection works, continue with the NAS connection and recovery workflow. Validate any exported files separately; resolving SSH access is not the same as recovering complete content.
For the next step, see XRecovery 4.0 Support: Find the Right Workflow for Your Next Step.