Incorrect fs sizes with SFTP mount

Help and Support
1

What is the problem you are having with rclone?

SFTP mount sizes don't seem to play well against servers with nested mounts. I've tried looking for similar reports and this seems to hint at the same thing Rclone windows mount size help .

rclone about shows the correct size

❯ rclone about sftp.internal:/media/videos/
Total:   1.921 TiB
Used:    896.584 GiB
Free:    1.046 TiB

df shows the size of the root filesystem of the server that is serving the nested mounts

❯ df -h ~/.mnt/sftp.internal/
Filesystem      Size  Used Avail Use% Mounted on
sftp.internal:  9.8G  1.7G  8.1G  18% /home/eric/.mnt/sftp.internal

❯ df -h ~/.mnt/sftp.internal/media/videos
Filesystem      Size  Used Avail Use% Mounted on
sftp.internal:  9.8G  1.7G  8.1G  18% /home/eric/.mnt/sftp.internal

sshfs does not have the same issue

❯ sshfs sftp.internal: .mnt/sshfs -p 8022 -o IdentityFile=~/.ssh/key

❯ df -h ~/.mnt/sshfs/
Filesystem      Size  Used Avail Use% Mounted on
sftp.internal:  9.8G  1.7G  7.6G  19% /home/eric/.mnt/sshfs

❯ df -h ~/.mnt/sshfs/media/videos
Filesystem           Size  Used Avail Use% Mounted on
sftp.internal:  2.0T  897G  981G  48% /home/eric/.mnt/sshfs

For bigger operations, I run rclone copy to the remote host directly, but sometimes for quicker operations I'd like to be able to just drag and drop in my file explorer. Dolphin reports the same thing that df does (8.1G available).

Run the command 'rclone version' and share the full output of the command.

❯ rclone version
rclone v1.75.0
- os/version: arch (64 bit)
- os/kernel: 7.1.8-arch1-3 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.26.5-X:nodwarf5
- go/linking: dynamic
- go/tags: none

Which cloud storage system are you using? (eg Google Drive)

SFTP

The command you were trying to run (eg rclone copy /tmp remote:tmp)

It's in a systemd unit, but the mount itself isn't the issue.

  /usr/bin/rclone mount \
    --config=%h/.config/rclone/rclone.conf \
    --vfs-cache-mode writes \
    --vfs-read-chunk-size 1M \
    --vfs-read-ahead 0 \
    --buffer-size 16M \
    --dir-cache-time 1m \
    --poll-interval 0 \
    --transfers 12 \
    --rc \
    --rc-no-auth \
    --rc-addr=unix:///tmp/rclone-rc-%i.sock \
    --log-level INFO \
    --log-file /tmp/rclone-%i.log \
    --cache-dir /tmp/rclone \
    --umask 022 \
    --allow-other \
    %i: %h/.mnt/%i

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

❯ rclone config redacted
[sftp.internal]
type = sftp
host = XXX
port = 8022
user = XXX
key_file = /home/eric/.ssh/key
concurrency = 128
chunk_size = 250Ki
shell_type = unix
md5sum_command = none
sha1sum_command = none
2

The About operation which powers rclone about and statfs which powers df only returns the result for the root of the file system.

When you do rclone about sftp.internal:/media/videos you are setting the root to /media/videos but the df from the mount uses the root passed to the mount.

So what you are seeing is expected behaviour.

I hope that makes sense!

This could be changed of course, but it would mean changing every backend (or making an extra AboutPath call which takes a path) which would be a lot of work, especially since most backends only support usage at the root anyway.

3

df shows the root mount's size, not the subfolder — that's why /media/videos looks off. rclone about on that exact path gives the correct number, since rclone's size reporting only works at the root per backend, not for nested paths.

run rclone about directly on the subfolder instead of df

4

Makes sense, thanks! To be clear, the main pain point is that if I tried to drag and drop a 10G file into the mount, dolphin would flat out reject the operation since it thinks the destination is too small. It's not a huge deal since larger transfers are better served via rclone copy directly rather than letting the host interact with a mount.

I might poke around the source and see how much of a pain extending the Abouter interface would be. My naive assumption is that maybe everything could just implement AboutPath() to just call return About() as a backwards compat strategy, but I know what happens when people assume :stuck_out_tongue:

5

I'd make a shim in fs - say fs.GetAboutPath(f fs.Fs, path string) which tried to see if f has AboutPath and falls back to About if not. Then implement AboutPath for backends which could use it (local, sftp, nfs (maybe), smb (maybe)) and drop the shim into the 3 mount commands.