[Bug]: copying the same file twice with scp to S3 backed user fails second time

[gerardkok]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).

Bug description

Copying the same file twice with scp to a user with its home directory on S3, results in a failure the second time:

% scp random.img demo.sftp@sftpgo.example.com:
random.img                                                           100% 8192KB  16.1MB/s   00:00    
scp: remote fsetstat: Operation unsupported
% scp random.img demo.sftp@sftpgo.example.com:
scp: dest open "./random.img": Operation unsupported
scp: failed to upload file random.img to .

(the warning 'scp: remote fsetstat: Operation unsupported' is harmless)

Running scp with -vv has these debug lines around the failure:

scp: debug2: Remote version: 3
scp: debug2: Server supports extension "statvfs@openssh.com" revision 2
scp: debug2: Sending SSH2_FXP_STAT "."
scp: debug2: sftp_upload: upload local "random.img" to remote "./random.img"
scp: debug2: Sending SSH2_FXP_OPEN "./random.img"
scp: dest open "./random.img": Operation unsupported
scp: failed to upload file random.img to .

Steps to reproduce

1. Set up SFTPGo with a user with a home directory backed by S3, and arrange logging in with SSH
2. Copy a file using scp to the user from step 1
3. Copy the same file a second time using scp to the same destination

Expected behavior

That copying would also work fine the second time around, i.e.:

% scp random.img demo.sftp@sftpgo.example.com:
random.img                                                           100% 8192KB  16.1MB/s   00:00    
scp: remote fsetstat: Operation unsupported
% scp random.img demo.sftp@sftpgo.example.com:
random.img                                                           100% 8192KB  16.1MB/s   00:00    
scp: remote fsetstat: Operation unsupported

SFTPGo version

2.7.0

Data provider

Postgres (AWS RDS Postgres 17.4)

Installation method

Community Deb package

Configuration

SFTPGo is running on Ubuntu 24.04 on an AWS arm64 instance. The S3 backend used is AWS S3. I've swapped SSH ports, such that SFTPGo runs on port 22, and the OS's SSH daemon runs on 222:

SFTPGO_SFTPD__BINDINGS__0__PORT=22

The only other non-standard setting is:

SFTPGO_COMMON__SETSTAT_MODE=2

Other settings are standard, i.e. point SFTPGo to the database, set the Let's Encrypt certificate, etc.

The home directories are in a single S3 bucket, each user in its own folder. To access the user's folder in the bucket, each user has its own AWS IAM role, that the instance can assume via its instance role (i.e. no secret and access keys are used). The user role look as follows:

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::<bucket>",
            "Condition": {
                "StringLike": {
                    "s3:prefix": "demo.sftp/*"
                }
            }
        },
        {
            "Action": [
                "s3:AbortMultipartUpload",
                "s3:DeleteObject",
                "s3:GetObject",
                "s3:GetObjectAttributes",
                "s3:ListMultipartUploadParts",
                "s3:PutObject"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::<bucket>/demo.sftp/*"
        }
    ],
    "Version": "2012-10-17"
}

Relevant log output

{"level":"debug","time":"2025-11-21T08:50:40.858","sender":"SFTP","connection_id":"SFTP_46b8c649c41e6eaec046f70b8cd7b45fd227de6f3b1b3152c6ac93747bb18dfd_1","message":"unable to get max write size for file \"/random.img\" is resume? true: operation unsupported"}

What are you using SFTPGo for?

Medium business

Additional info

I think this happens when scp is using the 'SFTP protocol' under the hood, which on OpenSSH is the default since version 8.6 (https://www.openssh.org/releasenotes.html). I used scp that comes standard with macOS 26.1 (OpenSSH_10.0p2, LibreSSL 3.3.6).

Workarounds:

• use the legacy SCP protocol by using the -O flag:

% scp -O random.img demo.sftp@sftpgo.example.com:
random.img                                                           100% 8192KB  12.2MB/s   00:00

• use the sftp command instead of scp:

sftp demo.sftp@sftpgo.example.com <<< $'put random.img'

[marziaelia]

Thanks for reporting this issue. Could you please try our Enterprise version (also) available on the AWS Marketplace? I'm not entirely sure, but this issue may not be present there:

https://docs.sftpgo.com/enterprise/installation/#aws

[gerardkok]

I tested this on a stock Enterprise Starter AMI (version SFTPGo 93a9a83e); I only set an admin password, and created a user with storage on a new S3 bucket). And on this version copying the same file twice indeed works fine:

[ec2-user@ip-172-31-21-142 ~]$ scp -P 2022 random.img gerard@localhost:
random.img                                                                  100% 1024KB 257.7MB/s   00:00    
Couldn't fsetstat: Operation unsupported
[ec2-user@ip-172-31-21-142 ~]$ scp -P 2022 random.img gerard@localhost:
random.img                                                                  100% 1024KB 208.7MB/s   00:00    
Couldn't fsetstat: Operation unsupported

[drakkan]

I tested this on a stock Enterprise Starter AMI (version SFTPGo 93a9a83e); I only set an admin password, and created a user with storage on a new S3 bucket). And on this version copying the same file twice indeed works fine:

Thanks for confirming. I believe this was originally fixed in v2.7.20251009 ("Upload Resume: Fixed edge cases related to resuming uploads with cloud storage backends") and further improved in v2.7.20251107 ("Upload Resume: Improved and finalized the fix introduced in v2.7.20251009"). Full changelog.

Our work queue is quite full at the moment, but I’ll try to find time to extract the relevant part in the future. Thanks for your patience.