The following – whether this is a good idea aside – appears not to work:

me@client:~ $ ssh host
me@host:~ $ cd /media/big-hdd
me@host:/media/big-hdd $ sudo fallocate -l 8g swapfile
me@host:/media/big-hdd $ sudo chown me swapfile
me@host:/media/big-hdd $ logout
me@client:~ $ sudo mkdir /media/big-hdd
me@client:~ $ sudo sshfs me@host:/media/big-hdd /media/big-hdd
me@client:~ $ sudo mkswap /media/big-hdd/swapfile
Setting up swapspace version 1, size = 8388604 KiB
no label, UUID=7d6b9704-7692-4463-b0c7-8a94668d715f
me@client:~ $ sudo swapon /media/big-hdd/swapfile
swapon: /media/big-hdd/swapfile: insecure permissions 0644, 0600 suggested.
swapon: /media/big-hdd/swapfile: insecure file owner 1002, 0 (root) suggested.
swapon: /media/big-hdd/swapfile: swapon failed: Invalid argument

It was suggested elsewhere that this Invalid argument problem is because fallocate does not actually allocate, only reserve the memory. But replacing it with the (much slower)

me@host:/media/big-hdd $ sudo dd if=/dev/zero of=swapfile count=2048 bs=4MiB

also doesn't change anything.

Is this just in principle not possible, or am I just making a mistake that prevents it from working?

  • check out nbd, network block devices.
    – meuh
    Apr 2, 2017 at 9:57

2 Answers 2


This is not possible over sshfs due to the way that it implements the filesystem.

Essentially it maps the client side of the filesystem to a series of sftp file transfers. You update a file locally and sshfs copies that file (in its entirety) remotely. Here's what the man page itself has to say:

On the local computer where the SSHFS is mounted, the implementation makes use of the FUSE (Filesystem in Userspace) kernel module. The practical effect of this is that the end user can seamlessly interact with remote files being securely served over SSH just as if they were local files on his/her computer. On the remote computer the SFTP subsystem of SSH is used.

Futhermore, bear in mind that FUSE is implemented in user space and so is subject to swapping. Consider the effect on a system that is already swapping, where the FUSE subsystem is called, but in order to run it needs to swap out another process (or worse, swap itself back in again)...

It would be possible over a block-based filesystem such as NFS, and indeed this was used on early diskless systems in the 80s/90s.


Surprisingly for me, it doesn't work directly. Both swapon <swapfile-on-ssh> and swapon -o loop <swapfile-on-ssh> fail with Invalid argument, with swapon: swapfile has holes in logs.

But works via losetup:

losetup -f <swapfile>
losetup # To take a look which device I've got
swapon /dev/loop<N>

I've used this trick to build gcc on raspberry 3. Note that concerns from other reply (sshfs itself may be subject to swapping) still remain.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .