Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
SFTP Transfer Disconnects: Diagnose Without Data Loss
Ryan Foster
October 7, 2026· 11 min read
When an SFTP transfer disconnects, preserve the original file and any partial copy before retrying. Identify whether the SSH session failed to start SFTP, closed while idle, or stopped during a file operation; then compare one safe transfer and review the server's evidence before attempting recovery.
Key Takeaways:
- SSH login and a working SFTP subsystem are separate observations.
- Record time, bytes, operation, and the exact error rather than assuming a network cause.
- Resume only when the partial copy belongs to the unchanged original.
- Keep host-key verification, permissions, and production files intact during diagnosis.
Step 1: What should you record when an SFTP transfer disconnects?
Record the client/version, operating system, authorized server, account role, operation, filename category, size, and exact error. Mark the time zone and time when progress began and when it stopped. Note whether no file bytes moved, some moved, or the client declared completion before the session closed.
SFTP is the SSH file-transfer subsystem, not FTP with TLS. WinSCP documents server-side causes of unexpected closure, including a missing or inaccessible SFTP subsystem and problems while starting the required session.［1］ Successful SSH access is therefore useful context without proving that every SFTP operation works.
Stop automatic transfers while collecting one example, particularly when they target a production directory. Keep the local source intact and preserve the remote partial file under its existing identity. Do not start a second client writing the same path while the first session's state is uncertain.
If the service is FTPS, use the control-versus-data connection workflow. FTPS listing failures can involve a separate data connection; this article stays with SSH/SFTP session and recovery behavior. The SSH and VPN comparison explains their different responsibilities.
If several unrelated applications also fail, start with the device and app baseline checks before changing this client.
Step 2: Can the server start the intended SFTP session?
Connect using the server's documented hostname, port, and approved authentication. Verify its host key through the service's trusted process. If a previously known key changes unexpectedly, stop and confirm the change with the administrator; do not clear known_hosts or accept a replacement merely to continue a transfer.
Try a permitted directory listing without uploading anything. If the session closes before a listing, ask the owner to inspect the SFTP subsystem and account restrictions at the same timestamp. WinSCP's unexpected-close guidance recommends checking whether the failure is client-specific or server-related and using server logs for the actual cause.［1］
A comparison with another approved SFTP client should keep the account, host, and requested read operation the same. Do not use a more privileged account to make the result look successful. A shell available to one account or a browser file portal does not establish SFTP access for the affected account.
Stop at an explicit authentication or subsystem error. That evidence calls for the server's owner rather than a longer client timeout. Record “session could not start SFTP” separately from “SFTP started and the transfer later disconnected” so the administrator does not investigate the wrong phase.
Step 3: Are permissions or storage rejecting the operation?
Check the intended remote directory and whether the account may perform the requested operation there. Listing, reading, creating, replacing, and renaming are different permissions. A visible directory does not prove that you can upload into it or replace an existing file.
For a server you administer, inspect free space, applicable user quotas, volume state, and relevant service logs using its supported tools. Otherwise, ask the administrator for those checks. The file-permission guide and disk-space workflow explain the corresponding server-side branches without requiring you to change ownership or delete data blindly.
If the same safe operation fails at the same path with an explicit storage or access error, resolve that condition before more network experiments. Do not broadly grant write permissions, use root as a transfer account, or delete unrelated server files to create space.
Also check local destination space and permissions for downloads. Preserve the partial copy and its location while deciding what failed. A local disk filling during a download is not evidence that the remote server or VPN lost the connection, even if the client ends the session afterward.
Step 4: Is closure tied to idle time or active transfer?
Compare elapsed time with actual progress. A session left idle and a file actively moving bytes exercise different conditions. Record whether closure occurs after similar idle intervals, similar transfer durations, or similar byte counts, and whether the client reports a server disconnect reason.
Ask the server owner to correlate the timestamp with service, policy, and storage logs. A consistent time boundary can reflect policy or a network device, but timing alone does not identify which one. Do not infer “the server has a fixed limit” from one interrupted attempt.
Client keepalive settings can help certain idle-session situations, but they are not a cure for disk errors, active-transfer failures, or unsupported authentication. Change only a vendor-documented setting that fits the observed idle pattern, preserve its original value, and verify the outcome. Never disable server policy to keep a personal test connected.
SSH can also renegotiate encryption keys during a session. If a log points to that phase, give the owner the precise client/server versions and error. Do not turn off security mechanisms or guess larger rekey limits to conceal incompatibility; a supported version or configuration correction belongs with the responsible owner.
Step 5: What does a small-versus-long transfer show?
Choose a harmless file you own and a new test destination the account may write. First transfer one small file, then verify its actual contents at the destination. Only if needed, compare a modest larger test file or a longer permitted transfer with the same client and server configuration.
Keep the test comfortably within storage, quota, and network allowances. Do not repeatedly upload a production backup just to obtain a longer duration. If a test would create excessive cost or load, ask the service owner for an approved sample instead.
| Observation | Useful next branch |
|---|---|
| Session closes before listing | Authentication, subsystem, or startup policy |
| Listing works; write is rejected | Directory permission, storage, or file operation |
| Small transfer works; longer transfer closes | Duration, progress, path, and server logs |
| Only idle sessions close | Documented idle policy or keepalive investigation |
| Transfer finishes; content differs | File identity and integrity investigation |
| Every client fails at the same operation | Server or shared-path correlation |
A small transfer succeeding while a longer one stops is a clue, not a benchmark or proof of one specific network defect. The file-transfer stall guide provides additional path distinctions. Preserve the exact byte count and elapsed time instead of interpreting a frozen percentage as a diagnosis.
Step 6: Does the authorized outbound route affect closure?
Compare routes only when the server, account, host key, storage, and test destination are confirmed and network policy permits it. Preserve a baseline using the same file and operation. Keep the client, account, hostname, remote path, and transfer settings fixed; vary only the approved connection path.
For the Windows SFTP client, connect AethoVPN on that same computer with Pro or Premium, enable global mode, and choose one currently available nearby position. Repeat the small transfer before any longer comparison, recording the byte count and closing time, then inspect the test file at its destination. On Mac, obtain the VPN client configuration through the website's setup guide with Pro or Premium. A changed outbound path does not grant SFTP permission, repair a full disk, or prove that a partial file is safe to resume; register to begin a 3-day free Pro transfer-path test, offered once per user and starting at registration.
If only the route changes and the original failure no longer appears, retain that limited observation with its timestamp. Do not promise stable long transfers from a single success. If both paths fail with the same explicit server condition, stop changing positions and involve the owner.
A private service may depend on an enterprise tunnel, an allowlisted address, or a managed-device requirement. Keep those conditions intact; a consumer VPN is not a substitute for its authorized access path. The tunnel checks before an SFTP retry can establish the tunnel state, while the SFTP transfer and file check remain the task's acceptance evidence.
Step 7: When is SFTP transfer resumption safe?
Before resuming, verify which side contains the partial copy, its path, its byte count, and whether the source changed after the failed attempt. Preserve the original and the partial file until their relationship is understood. Similar names or a smaller size are not sufficient proof that the partial data matches the source prefix.
OpenSSH's sftp manual warns that resume assumes the partial file matches the original; differing contents can produce corruption. Its get -a resumes a download, while other upload/resume commands have their own direction and behavior.［2］ Do not paste a resume command without understanding which file it modifies.
WinSCP documents resume support and its restrictions.［3］ Use the matching documentation for your client's current version, and inspect the overwrite/resume choice before accepting it.［4］ The official transfer-settings illustration below helps locate client controls; it is not evidence that the reader's file is resumable.
If the source may have changed or the partial copy cannot be verified, start a fresh transfer into a new authorized test location instead of modifying the uncertain partial. For production data, ask its owner to define the recovery procedure. Do not rename a partial file into a final production path solely because the transfer reached its expected size.
| Recovery evidence | Safe decision |
|---|---|
| Source unchanged, partial prefix verified, client supports resume | Follow the documented resume direction, then verify completed contents |
| Source changed or partial relationship unknown | Preserve both files; transfer afresh to a new approved location |
| Another writer may still be active | Stop and coordinate with the file owner before any write |
| Destination is production data or overwrite choice is unclear | Stop; have the owner approve the recovery procedure |
| Expected size reached but content verification failed | Do not accept or rename the copy as complete |
Step 8: How do you finish recovery and escalation safely?
After a completed test transfer, compare actual contents with the unchanged source. Use an owner-provided integrity value or an approved comparison where available; do not invent a reference value. File size and a successful session exit cannot independently establish content integrity.
Prepare a sanitized incident report containing versions, host/account role, operation, timestamp, elapsed time, byte count, small/long comparison, path comparison, and server error if available. Include the original versus partial identity decision and whether any resume was attempted. Keep credentials, private filenames, keys, and unreviewed logs out of public reports.
Restore temporary diagnostic settings and preserve recovery material until the file owner confirms acceptance. Do not delete the only complete source or remove an uncertain partial just to tidy the directory. Return to production transfers only when the failure branch and safe recovery procedure are clear.
Summary
- Locate startup, idle, active-transfer, and file-operation failures separately.
- Correlate timestamps with server evidence and safe test transfers.
- Compare only an authorized route while preserving host trust.
- Verify source/partial identity before resume and actual content afterward.
FAQ
Why can SSH login work while SFTP closes immediately?
The account may authenticate without being able to start the required SFTP subsystem. Ask the server owner to inspect startup restrictions and logs rather than treating shell access as proof of file-transfer support.［1］
Will keepalives repair every disconnection?
Keepalives address particular idle-session conditions. They do not correct permissions, full disks, active-transfer errors, or an incompatible server configuration.
Can I clear known_hosts when a connection fails?
Keep the trust record. An unexpected host-key change requires confirmation through the service's trusted channel; deleting the record removes evidence instead of resolving the identity question.
Is a smaller partial file always safe to resume?
A smaller size does not prove a matching prefix. Verify the source has not changed and that the partial belongs to it; otherwise resumption can produce corrupt contents.［2］
Does successful listing prove that upload is permitted?
Listing and uploading are separate file operations with different permission and storage requirements. Test an authorized new destination before interpreting read access as write access.
Is one long transfer enough to claim reliability?
One successful transfer validates only that file and those conditions at that time. Preserve the result without turning it into an availability, speed, or long-session guarantee.
What if both routes show the same disk or permission error?
Stop network experiments and resolve the named server condition with its owner. Repeating the same rejected write through another exit does not create storage or access rights.
Disclaimer: Transfer only authorized files and preserve originals. This workflow does not authorize changing host trust, weakening SSH security, overwriting production data, or bypassing organization access policy.
Sources
- WinSCP — Server unexpectedly closed network connection — https://winscp.net/eng/docs/message_unexpected_close
- OpenBSD — sftp manual — https://man.openbsd.org/sftp
- WinSCP — Resume and Append — https://winscp.net/eng/docs/resume
- WinSCP — Transfer Settings Dialog — https://winscp.net/eng/docs/ui_transfer_custom
Sources checked 7 October 2026.
