SFTP "Cannot open file in mode" on AWS Transfer

Your SFTP client or script signs in to an AWS Transfer Family server, then the upload fails as soon as it opens the remote file:

sftp: "Cannot open file in mode: WRITE|TRUNCATE|CREATE|READ" (SSH_FX_OP_UNSUPPORTED)

The list of modes can come in a different order, and some libraries add EXCLUSIVE. SSH.NET reports it like this:

Renci.SshNet.Common.SshException: Cannot open file in mode: CREATE|EXCLUSIVE|READ|WRITE

Why it happens

Every SFTP upload starts with an open request that says what the client wants to do with the file. AWS Transfer Family does not support opening a file for reading and writing at the same time, and answers that request with SSH_FX_OP_UNSUPPORTED (status code 8). Some libraries ask for read and write whenever you "create" a file, even though an upload never reads from it. That is why the same account usually uploads fine from OpenSSH sftp, WinSCP or FileZilla while your script fails. AWS's Transfer Family troubleshooting pages don't list this error; the Go pkg/sftp library documents the limit on its Create function.

How to fix it

Open the remote file write-only: write + create + truncate, no read.

Go (github.com/pkg/sftp). client.Create opens read/write. Use OpenFile instead:

// Before - asks for READ|WRITE|CREAT|TRUNC
f, err := client.Create(path)

// After - write-only
f, err := client.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_TRUNC)

.NET (SSH.NET). SftpClient.Create(path) and Open(path, mode) both default to FileAccess.ReadWrite. Pass write access explicitly, or use UploadFile, which opens write-only:

using (var remote = client.Open(path, FileMode.Create, FileAccess.Write))
{
    local.CopyTo(remote);
}

// or
client.UploadFile(local, path);

Python (paramiko). sftp.put() and sftp.open(path, "wb") are already write-only. Any mode with a + ("w+", "r+", "a+") adds read access and fails. paramiko raises it as an OSError with the same text.

with sftp.open(remote_path, "wb") as f:   # not "w+"
    f.write(data)

For any other library, find the call that opens or creates the remote file and make sure it asks for write access only.

If the error changes to "No such file"

Once the open mode is fixed, an upload straight into / can still fail. When a Transfer Family user has logical directories, / is a virtual root and uploads into it fail with:

remote open("/file"): No such file or directory

Upload into a folder the account maps to instead. Sign in with OpenSSH sftp and run pwd and ls to see where you land and which folders exist.

If you deliver with DocEvent Channels

A channel's SFTP destination opens every delivery write-only, so it does not hit this error on a trading partner's AWS Transfer Family server. Versions before 12 September 2026 used a read/write open and failed with this error. If you saw it then, run Test connection on the endpoint again.

Test connection uses the same write-only open as a real delivery. It creates a small hidden file (.docevent-verify-<id>.tmp) in the endpoint's Directory, writes to it, checks the server lists it, and then tries to delete it. A passing test means deliveries will not fail at the open.

If the test says the server refused to create a file, often with "file does not exist", set Directory to the folder the partner's account can write to (see No such file above). If the partner's server only accepts known addresses, give them the channel static IP addresses.

Still stuck? Email support with the endpoint's test result.