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
 
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