Issue Plesk Backup Suddenly Fails on SSHFS: pmm-ras Returns EPERM After Years of Working

F

FloLa

Basic Pleskian
Hello everyone,

I am currently experiencing an issue with Plesk backups that had been working reliably for several years.

The backup itself is created successfully, but the subsequent export to a remote FTP repository fails with an “Operation not permitted” error.

My environment is:

Code: 
Plesk Obsidian: 18.0.79 Update 4
OS: Debian 13.6
plesk-backup-utilities: 18.0-v.debian.13+p18.0.79.3+t260720.0455

SSHFS: 3.7.3-1.2~deb13u1
FUSE: 3.17.2

DUMP_D and DUMP_TMP_D are both located on the same SSHFS mount:

Code: 
/mnt/sshfs/xxx

[email protected]:/home/Backups

Current mount options:

Code: 
rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other

The actual backup data and the .tzst archives are created successfully in DUMP_D.

Only the subsequent export to the remote FTP repository fails.

During the export, pmm-ras successfully creates a hardlink from DUMP_D to the temporary repository in DUMP_TMP_D:

Code: 
Link /mnt/sshfs/xxx/DUMP_D/domains/xxx.example.com/backup_pd_xxx.tzst
to /mnt/sshfs/xxx/DUMP_TMP_D/pmm-de-tmp-repo-xxx/backup_pd_xxx.tzst

Add file '/mnt/sshfs/xxx/DUMP_TMP_D/pmm-de-tmp-repo-xxx/backup_pd_xxx.tzst'
to archive as 'backup_pd_xxx.tzst'

Immediately afterwards, pmm-ras reports:

Code: 
Unable to remove file
/mnt/sshfs/xxx/DUMP_TMP_D/pmm-de-tmp-repo-xxx/backup_pd_xxx.tzst:

filesystem error: status: Operation not permitted

The final repository error is:

Code: 
Repository error: Failed to open the file
'/mnt/sshfs/xxx/DUMP_TMP_D/pmm-de-tmp-repo-xxx/backup_pd_xxx.tzst':

Operation not permitted

pmm-ras then cancels the export after only 1024 bytes:

Code: 
Cancel export
Finish upload: 1024 bytes transferred
pmm-ras finished. Exit code: 1

The same error occurs with both plain FTP and FTPS.

The FTP server log does not show any FTP-side error. Authentication, directory listing, passive data connection and STOR are accepted successfully.

The FTP server returns:

Code: 
150 Starting data transfer.
226 Operation successful

However, the client sends only 1024 bytes before pmm-ras cancels the export because of the local EPERM error.

Manual tests on the same SSHFS mount all succeed:

  • Creating a hardlink
  • Opening the hardlink
  • Unlinking the hardlink while it is open
  • Reading from the open file descriptor after unlink
  • Concurrent writer and reader access

There are no symbolic links in DUMP_D, DUMP_TMP_D or any of their parent directories.

This backup architecture had been working successfully for several years. The last confirmed successful backup using the same storage setup was on 23 July 2026.

A different Plesk server using SSHFS 2.10 still completes the same backup and export process successfully. The affected Debian 13 server uses SSHFS 3.7.3. However, this comparison alone does not prove that SSHFS is the cause.

Has anyone encountered the same issue with Plesk 18.0.79, SSHFS 3.7.3 or FUSE 3?

Could this be a pmm-ras regression or compatibility issue involving hardlinks, filesystem status checks or unlink operations on SSHFS/FUSE?

Please let me know if there is a known hotfix, a recommended mount option or any additional diagnostic information I should provide.

Any help or suggestions would be greatly appreciated.

Thank you in advance.
 
FloLa said:
Hello everyone,

I am currently experiencing an issue with Plesk backups that had been working reliably for several years.

The backup itself is created successfully, but the subsequent export to a remote FTP repository fails with an “Operation not permitted” error.

My environment is:

Code: 
Plesk Obsidian: 18.0.79 Update 4
OS: Debian 13.6
plesk-backup-utilities: 18.0-v.debian.13+p18.0.79.3+t260720.0455

SSHFS: 3.7.3-1.2~deb13u1
FUSE: 3.17.2

DUMP_D and DUMP_TMP_D are both located on the same SSHFS mount:

Code: 
/mnt/sshfs/xxx

[email protected]:/home/Backups

Current mount options:

Code: 
rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other

The actual backup data and the .tzst archives are created successfully in DUMP_D.

Only the subsequent export to the remote FTP repository fails.

During the export, pmm-ras successfully creates a hardlink from DUMP_D to the temporary repository in DUMP_TMP_D:

Code: 
Link /mnt/sshfs/xxx/DUMP_D/domains/xxx.example.com/backup_pd_xxx.tzst
to /mnt/sshfs/xxx/DUMP_TMP_D/pmm-de-tmp-repo-xxx/backup_pd_xxx.tzst

Add file '/mnt/sshfs/xxx/DUMP_TMP_D/pmm-de-tmp-repo-xxx/backup_pd_xxx.tzst'
to archive as 'backup_pd_xxx.tzst'

Immediately afterwards, pmm-ras reports:

Code: 
Unable to remove file
/mnt/sshfs/xxx/DUMP_TMP_D/pmm-de-tmp-repo-xxx/backup_pd_xxx.tzst:

filesystem error: status: Operation not permitted

The final repository error is:

Code: 
Repository error: Failed to open the file
'/mnt/sshfs/xxx/DUMP_TMP_D/pmm-de-tmp-repo-xxx/backup_pd_xxx.tzst':

Operation not permitted

pmm-ras then cancels the export after only 1024 bytes:

Code: 
Cancel export
Finish upload: 1024 bytes transferred
pmm-ras finished. Exit code: 1

The same error occurs with both plain FTP and FTPS.

The FTP server log does not show any FTP-side error. Authentication, directory listing, passive data connection and STOR are accepted successfully.

The FTP server returns:

Code: 
150 Starting data transfer.
226 Operation successful

However, the client sends only 1024 bytes before pmm-ras cancels the export because of the local EPERM error.

Manual tests on the same SSHFS mount all succeed:

  • Creating a hardlink
  • Opening the hardlink
  • Unlinking the hardlink while it is open
  • Reading from the open file descriptor after unlink
  • Concurrent writer and reader access

There are no symbolic links in DUMP_D, DUMP_TMP_D or any of their parent directories.

This backup architecture had been working successfully for several years. The last confirmed successful backup using the same storage setup was on 23 July 2026.

A different Plesk server using SSHFS 2.10 still completes the same backup and export process successfully. The affected Debian 13 server uses SSHFS 3.7.3. However, this comparison alone does not prove that SSHFS is the cause.

Has anyone encountered the same issue with Plesk 18.0.79, SSHFS 3.7.3 or FUSE 3?

Could this be a pmm-ras regression or compatibility issue involving hardlinks, filesystem status checks or unlink operations on SSHFS/FUSE?

Please let me know if there is a known hotfix, a recommended mount option or any additional diagnostic information I should provide.

Any help or suggestions would be greatly appreciated.

Thank you in advance.
Click to expand...

I would like to add another observation that may help narrow down the issue.

The problem is not limited to exporting the backup to the remote repository. Downloading the backup directly through the Plesk Backup Manager also fails.

Plesk lists the backup as successfully created with an expected size of approximately 14.1 GB. However, after clicking the download button, the browser immediately finishes downloading the following file:

Code: 
backup_2607300007.tar

The downloaded file is only 1,191 bytes in size instead of the expected 14.1 GB and is not a valid TAR archive.

The successfully created 14.1 GB backup in the Plesk Backup Manager:

1785417321435.png

The completed browser download with a file size of only 1,191 bytes.

1785417326388.png

The actual backup data in DUMP_D exists and was created successfully. However, Plesk is apparently unable to read or stream the backup correctly when the download is started.

This behavior seems consistent with the remote export issue described above, where pmm-ras also stops after transferring approximately 1,024 bytes. Therefore, the issue does not appear to be limited to FTP or FTPS. It may instead affect the backup staging or download process when DUMP_D and DUMP_TMP_D are located on the SSHFS/FUSE mount.

I also inspected the downloaded 1,191-byte file.

It does not contain any backup data. The file consists of exactly 1,024 zero bytes, followed by the following plain-text error message:

Code: 
Repository error: Failed to open the file '/mnt/sshfs/xxx/DUMP_TMP_D/pmm-de-tmp-repo-xxxxxx/backup_ext_dist_kernelcare-plesk_2607300007.tzst': Operation not permitted

The first 1,024 bytes correspond to two empty 512-byte TAR blocks. Therefore, the downloaded file is effectively an empty TAR archive followed by the repository error message.

This also directly matches the 1,024 bytes reported by pmm-ras during the failed remote export.

It confirms that Plesk fails while opening a file from DUMP_TMP_D on the SSHFS/FUSE mount and returns the repository error instead of the actual backup data.
 
Update: Root cause identified and workaround confirmed

I was able to reproduce and isolate the issue with a controlled A/B test on the same server, using the same Plesk configuration and the same SSHFS backup storage.

Test 1 – Current SSHFS version with default options

Code: 
sshfs 3.7.3-1.2~deb13u1

Result:

The backup export/download failed with:

Code: 
Operation not permitted
EPERM

The download stopped after only 1,024 bytes, resulting in an invalid 1,191-byte TAR file.

Test 2 – Downgrade to the previous SSHFS package

Code: 
sshfs 3.7.3-1.1+b2

Result:

The backup creation completed successfully and the backup could also be downloaded successfully through the Plesk Backup Manager.

Test 3 – Current SSHFS version with contain_symlinks disabled

I reinstalled the current Debian package:

Code: 
sshfs 3.7.3-1.2~deb13u1

The backup storage was then mounted with:

Code: 
sshfs root@<STORAGE_SERVER_IP>:/home/Backups /mnt/sshfs/nd0/ -o allow_other,no_contain_symlinks

Result:

The backup creation and subsequent download through the Plesk Backup Manager both completed successfully without any errors.

This confirms that the issue is triggered by the new default contain_symlinks behaviour in the current Debian SSHFS package.

The working workaround is:

Code: 
-o no_contain_symlinks

This allows the current SSHFS package to remain installed, so no downgrade or package hold is required.

What remains unusual is that there are no symbolic links anywhere in the relevant directories, including:

Code: 
DUMP_D
DUMP_TMP_D

According to the Plesk logs, pmm-ras creates a hardlink in the temporary repository, adds the file to the archive and then fails during its subsequent cleanup/opening workflow.

Nevertheless, disabling contain_symlinks completely resolves the issue.

It would therefore be useful if Plesk could investigate why the pmm-ras staging process triggers this SSHFS protection even though no symbolic links appear to be involved.

Confirmed working configuration:

Code: 
SSHFS version: 3.7.3-1.2~deb13u1
Mount options:  allow_other,no_contain_symlinks
 
Hi, @FloLa . I configured a Debian 13 server with the mentioned SSHFS version, but I can't seem to be able to replicate the issue. The backup is successfully created and transferred to the remote server (in full size).

Code: 
root@10-160-70-45:~# sshfs --version
dpkg -l sshfs fuse3
SSHFS version 3.7.3
FUSE library version 3.17.2
using FUSE kernel interface version 7.40
fusermount3 version: 3.17.2
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version           Architecture Description
+++-==============-=================-============-=====================================================
ii  fuse3          3.17.2-3          amd64        Filesystem in Userspace (3.x version)
ii  sshfs          3.7.3-1.2~deb13u1 amd64        filesystem client based on SSH File Transfer Protocol
root@10-160-70-45:~# findmnt -T /mnt/sshfs/backups -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET             SOURCE                          FSTYPE     OPTIONS
/mnt/sshfs/backups [email protected]:/home/Backups fuse.sshfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other
root@10-160-70-45:~# mount | grep sshfs
[email protected]:/home/Backups on /mnt/sshfs/backups type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

If you have the option, please open a ticket with our support team and grant them server access so the configuration could be reviewed locally.
 
Sebahat.hadzhi said:
Hi, @FloLa . I configured a Debian 13 server with the mentioned SSHFS version, but I can't seem to be able to replicate the issue. The backup is successfully created and transferred to the remote server (in full size).

Code: 
root@10-160-70-45:~# sshfs --version
dpkg -l sshfs fuse3
SSHFS version 3.7.3
FUSE library version 3.17.2
using FUSE kernel interface version 7.40
fusermount3 version: 3.17.2
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version           Architecture Description
+++-==============-=================-============-=====================================================
ii  fuse3          3.17.2-3          amd64        Filesystem in Userspace (3.x version)
ii  sshfs          3.7.3-1.2~deb13u1 amd64        filesystem client based on SSH File Transfer Protocol
root@10-160-70-45:~# findmnt -T /mnt/sshfs/backups -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET             SOURCE                          FSTYPE     OPTIONS
/mnt/sshfs/backups [email protected]:/home/Backups fuse.sshfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other
root@10-160-70-45:~# mount | grep sshfs
[email protected]:/home/Backups on /mnt/sshfs/backups type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

If you have the option, please open a ticket with our support team and grant them server access so the configuration could be reviewed locally.
Click to expand...

Hi @Sebahat.hadzhi , thank you for testing this.

My setup and workflow are slightly different from the one shown in your test.

The SSHFS mount is not the final remote backup destination. It is used as intermediate storage for Plesk so that the local filesystem of the Plesk server does not fill up while backups are being created.

The actual workflow is:

  1. Plesk creates the backup.
  2. DUMP_D and DUMP_TMP_D are both located on the SSHFS mount.
  3. The complete backup files are successfully created in DUMP_D.
  4. Afterwards, Plesk exports/transfers the completed backup from this repository to a separate external SFTP backup server.

The error occurs during step 4, not during the initial creation of the backup.

The complete backup files already exist on the SSHFS-mounted intermediate storage. When Plesk subsequently starts the export using pmm-ras, it creates a temporary repository below DUMP_TMP_D and links the existing backup files into it.

The log then shows that the file is added, but the following operation fails with:

Code: 
Operation not permitted

The transfer to the external SFTP server is then cancelled after only 1,024 bytes.

The external SFTP server itself accepts the connection and upload. However, Plesk aborts the transfer because of the local repository error on the SSHFS mount.

The same problem could also be reproduced by downloading the completed backup directly through the Plesk Backup Manager. Instead of the expected multi-gigabyte archive, Plesk returned an invalid TAR file of only 1,191 bytes containing the same repository error.

I tested the following configurations on exactly the same Plesk server, using the same SSHFS storage and the same external destination:

1. Current SSHFS package with default mount options

Code: 
sshfs 3.7.3-1.2~deb13u1
Mount options: allow_other

Result:

Code: 
The backup is successfully created in DUMP_D.

The subsequent export to the external SFTP server fails with EPERM after 1,024 bytes.

Downloading the backup through the Plesk Backup Manager also fails.

2. Previous SSHFS package

Code: 
sshfs 3.7.3-1.1+b2

Result:

Code: 
The backup is created successfully.

The subsequent transfer to the external SFTP server works.

The direct download through the Plesk Backup Manager also works.

3. Current SSHFS package with contain_symlinks disabled

Code: 
sshfs 3.7.3-1.2~deb13u1

Mounted with:

Code: 
sshfs root@<STORAGE_SERVER_IP>:/home/Backups /mnt/sshfs/nd0/ -o allow_other,no_contain_symlinks

Result:

Code: 
The backup is created successfully.

The subsequent transfer to the external SFTP server works.

The direct download through the Plesk Backup Manager also works.

Therefore, simply creating a backup directly on the SSHFS mount does not reproduce the issue.

The relevant test is exporting or downloading an already completed backup from the SSHFS-based Plesk repository through pmm-ras.

There are no symbolic links in DUMP_D, DUMP_TMP_D or their parent directories. The Plesk logs show hardlinks being used during the staging process.

Nevertheless, adding:

Code: 
-o no_contain_symlinks

completely resolves the issue while keeping the current Debian SSHFS package installed.

Could you please test the complete two-stage workflow, with the SSHFS mount used as the Plesk repository/intermediate storage and a subsequent export to another remote destination or a download through the Plesk Backup Manager?
 
You must log in or register to reply here.

Similar threads

enerspace
Internal backup over CIFS / SSHFS mount
Replies
12
Views
6K
Sebahat.hadzhi
Sebahat.hadzhi
S
Issue Full Plesk backup issues - very slow
Replies
5
Views
6K
Bitpalast
Bitpalast
G
Question Plesk Backup Manager Gateway Timeout
Replies
2
Views
3K
gedanggoreng
G
H
Backup Manager download Backup not working
Replies
4
Views
3K
Henri
H
T
Restore in Plesk 12.5 fails with "This operation is taking too long"
Replies
0
Views
1K
TomBoB
T
Back
Top