• Debian 11 is approaching its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.80 will be the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

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?
 
Sebahat.hadzhi said:
Hi, @FloLa . Apologies for the misunderstanding. Could you please open a report here:


and include instructions on how exactly the three servers in questions are currently configured and with STR.
Click to expand...

Hi Sebahat,

I tried to submit the requested report several times, but the form always fails with the following message:

Code: 
A server error occurred. Please try again later.

I also tried again without BBCode formatting, but the submission still failed. Therefore, I am providing the complete report information here.

TITLE

Plesk backup export and download fail with EPERM on SSHFS unless no_contain_symlinks is used

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

  • Plesk Obsidian: 18.0.79 Update 4
  • Operating system: Debian GNU/Linux 13.6
  • Architecture: x86_64 / amd64
  • 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
  • FUSE kernel interface: 7.40
  • fusermount3: 3.17.2

PROBLEM DESCRIPTION

The setup consists of three servers.

1. Plesk server

  • Plesk Obsidian: 18.0.79 Update 4
  • Operating system: Debian GNU/Linux 13.6
  • Architecture: x86_64 / amd64
  • 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
  • FUSE kernel interface: 7.40
  • fusermount3: 3.17.2

The Plesk backup repository is located on an SSHFS mount. It is used as intermediate storage so that the local filesystem of the Plesk server does not fill up while backups are being created.

Both DUMP_D and DUMP_TMP_D are located on the same SSHFS mount.

Failing mount configuration: sshfs root@STORAGE_SERVER:/home/Backups /mnt/sshfs/nd0/ -o allow_other

Effective mount options: rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other

2. SSHFS storage server

  • Operating system: Debian GNU/Linux 13
  • Architecture: x86_64 / amd64
  • SSHFS: 3.7.3-1.2~deb13u1
  • FUSE: 3.17.2
  • FUSE kernel interface: 7.40
  • fusermount3: 3.17.2

Role: Intermediate storage for the Plesk backup repository

Remote path: /home/Backups

Access method: SSH/SFTP through SSHFS

3. External backup server

  • Operating system: Microsoft Windows Server
  • Architecture: x86_64
  • Backup server software: FileZilla Server 1.12.6
  • Protocol: FTP

Role: Final external backup destination

The completed Plesk backup is transferred from the SSHFS-based intermediate storage to this Windows FileZilla FTP server.

The backup itself is created successfully and the complete .tzst files exist in DUMP_D on the SSHFS mount. The problem occurs afterwards, when Plesk exports the completed backup to the external server or when the backup is downloaded through the Plesk Backup Manager.

During the export or download, pmm-ras creates a temporary repository below DUMP_TMP_D and creates hardlinks to the existing backup files. The log shows that the file is linked and added to the archive, but pmm-ras then fails with:

Code: 
filesystem error: status: Operation not permitted
Repository error: Failed to open the file '/mnt/sshfs/nd0/DUMP_TMP_D/pmm-de-tmp-repo-.../backup_....tzst': Operation not permitted

The transfer is cancelled after exactly 1,024 bytes.

The same problem can be reproduced without the external FTP server by downloading the completed backup through the Plesk Backup Manager. Instead of the expected multi-gigabyte archive, Plesk returns an invalid 1,191-byte TAR file. It contains 1,024 zero bytes followed by the repository error message.

There are no symbolic links in DUMP_D, DUMP_TMP_D or their parent directories. According to the Plesk log, pmm-ras uses hardlinks during the staging process.

STEPS TO REPRODUCE

  1. Use a Plesk server running Debian GNU/Linux 13.6 with Plesk Obsidian 18.0.79 Update 4, SSHFS 3.7.3-1.2~deb13u1 and FUSE 3.17.2.
  2. Use a separate Debian 13 server as intermediate backup storage. The remote path is /home/Backups.
  3. Mount the storage directory on the Plesk server with: sshfs root@STORAGE_SERVER:/home/Backups /mnt/sshfs/nd0/ -o allow_other
  4. Do not use no_contain_symlinks for the initial reproduction.
  5. Configure DUMP_D as /mnt/sshfs/nd0/DUMP_D and DUMP_TMP_D as /mnt/sshfs/nd0/DUMP_TMP_D.
  6. Configure a separate Microsoft Windows Server running FileZilla Server 1.12.6 as the final external FTP backup destination.
  7. Start a full Plesk server backup and wait until it has been created successfully.
  8. Verify that the complete backup files and .tzst archives exist in DUMP_D on the SSHFS mount.
  9. Allow Plesk to export the completed backup to the external FileZilla FTP server.
  10. Observe that pmm-ras creates a temporary repository below DUMP_TMP_D, links the existing backup files and then fails with EPERM.
  11. Observe that the FTP transfer is cancelled after 1,024 bytes.
  12. Alternatively, download the successfully completed backup through the Plesk Backup Manager and observe that only an invalid 1,191-byte TAR file is returned.
  13. Unmount the SSHFS filesystem and mount it again with: sshfs root@STORAGE_SERVER:/home/Backups /mnt/sshfs/nd0/ -o allow_other,no_contain_symlinks
  14. Repeat the export or download. The same completed backup can now be exported and downloaded successfully.

The relevant pmm-ras sequence is:

Code: 
Link /mnt/sshfs/nd0/DUMP_D/.../backup_....tzst to /mnt/sshfs/nd0/DUMP_TMP_D/pmm-de-tmp-repo-.../backup_....tzst
Add file '/mnt/sshfs/nd0/DUMP_TMP_D/pmm-de-tmp-repo-.../backup_....tzst' to archive as 'backup_....tzst'
filesystem error: status: Operation not permitted
Repository error: Failed to open the file '/mnt/sshfs/nd0/DUMP_TMP_D/pmm-de-tmp-repo-.../backup_....tzst': Operation not permitted

ACTUAL RESULT

The backup itself is created successfully and all backup data exists in DUMP_D.

The failure occurs afterwards, when pmm-ras attempts to export or download the completed backup from the SSHFS-based repository.

Error: Repository error: Failed to open the file '/mnt/sshfs/nd0/DUMP_TMP_D/pmm-de-tmp-repo-.../backup_....tzst': Operation not permitted

FTP result: The external FileZilla server accepts the connection, authentication, passive data connection and upload command. However, Plesk sends only 1,024 bytes before cancelling the operation because of the local repository error.

Backup Manager result: Instead of the expected multi-gigabyte archive, Plesk returns an invalid 1,191-byte TAR file containing 1,024 zero bytes followed by the repository error.

Affected configuration: SSHFS 3.7.3-1.2~deb13u1 with mount option allow_other

Workaround: Adding no_contain_symlinks resolves the issue completely.

EXPECTED RESULT

Plesk should be able to export and download a successfully completed backup from an SSHFS-based Plesk repository.

The completed backup should be transferred in full from the intermediate SSHFS storage to the external FileZilla FTP server. Downloading the same backup through the Plesk Backup Manager should also return the complete and valid archive.

The pmm-ras staging process should not fail with EPERM when no symbolic links exist in DUMP_D, DUMP_TMP_D or their parent directories.

The export and download should work with the default SSHFS configuration without requiring -o no_contain_symlinks.

ANY ADDITIONAL INFORMATION

All A/B tests were performed on the same Plesk server with the same Plesk configuration, Debian storage server, SSHFS repository, external Windows FileZilla FTP server and completed Plesk backup.

Test 1: Current SSHFS package with default mount options

SSHFS version: 3.7.3-1.2~deb13u1

Mount options: allow_other

Result: Backup creation in DUMP_D succeeds. Export to the external FTP server fails with EPERM. The transfer stops after 1,024 bytes. Downloading through the Plesk Backup Manager fails and the downloaded TAR file has a size of only 1,191 bytes.

Test 2: Previous SSHFS package

SSHFS version: 3.7.3-1.1+b2

Mount options: allow_other

Result: Backup creation succeeds. Export to the external FTP server succeeds. Downloading through the Plesk Backup Manager succeeds.

Test 3: Current SSHFS package with contain_symlinks disabled

SSHFS version: 3.7.3-1.2~deb13u1

Mount options: allow_other,no_contain_symlinks

Result: Backup creation succeeds. Export to the external FTP server succeeds. Downloading through the Plesk Backup Manager succeeds.

The last confirmed successful backup using the previously working configuration was on 23 July 2026.

Manual filesystem tests on the affected SSHFS mount were also successful:

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

There are no symbolic links in DUMP_D, DUMP_TMP_D or their parent directories. According to the Plesk log, pmm-ras creates hardlinks during the temporary staging process.

Nevertheless, the current SSHFS contain_symlinks behaviour causes the Plesk operation to fail with EPERM. Disabling this behaviour with -o no_contain_symlinks resolves the issue completely.

The workaround allows the current Debian SSHFS package to remain installed. No downgrade or package hold is required.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm Bug
 
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
7K
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