problem with the local beta backup

I notice this problem with the local beta backup


I am encountering an issue with the local backup restore feature (beta version).

Hello,

We are experiencing a problem with the new local backup restore feature on our server.

The backup files are present on the server and appear to be complete and intact. However, the restore process does not start correctly.

Whenever we attempt to restore an account, the process consistently gets stuck at the "Detecting files" stage and makes no further progress.

The restore log repeatedly shows the following information:

2026-07-07 14:14:06 UPDATE restore SET ST='20260707201406' WHERE ST='1'
2026-07-07 14:14:06 >>>>>>>>> [1,1,1,1,1,1,1,1,1,grizzy,2026-06-27_17-15-04,0,,1,1,1,1,1]
2026-07-07 14:14:06 Detecting files

We have verified that the backup directory exists and that all backup archives are available.

Based on our investigation, it appears that the restore utility is generating an incorrect path and attempting to locate a non-existent backup archive, even though the backup data is available at the correct location.

Could you please check if this is a known issue with this new local backup restore feature?

If so, is there a fix, a workaround, or an updated restore procedure available to successfully restore the accounts?

Bug Report – CWP SFTP Backup Compatibility with SFTPGo

Hello,

I would like to report what appears to be a compatibility issue between the CWP SFTP backup feature and SFTPGo.

Environment
CWP: Latest available version
Backup Server: SFTPGo (latest Docker image)
Protocol: SFTP / SSH
Port: 22
Authentication: Username + Password
Issue Description

When configuring an SFTP backup destination in CWP, the connection always fails with the following error:

Login Failed:
Permission denied, please try again.
Received disconnect from xxx.xxx.xxx.xxx port 22:2:
too many authentication failures

At first glance, this appears to be an authentication problem, but after analyzing the SFTPGo server logs, the issue is actually different.

Investigation

The SFTPGo logs show that CWP performs several authentication attempts in the following order:

Public Key authentication
Keyboard-Interactive authentication (without credentials)
Password authentication (without credentials)
Finally, a successful login using keyboard-interactive authentication.

Immediately after the successful authentication, CWP executes the following remote command:

mkdir -p ~/.ssh &&
chmod 700 ~/.ssh &&
echo <public_key> >> ~/.ssh/authorized_keys &&
chmod 600 ~/.ssh/authorized_keys

However, SFTPGo is a pure SFTP server and does not provide an interactive shell.

As a result, SFTPGo returns:

ssh command not enabled/supported: "mkdir"

and the session is terminated.

Root Cause

The current implementation appears to assume that every SFTP server also provides a full SSH shell.

This assumption is not always valid.

Modern SFTP servers such as:

SFTPGo
AWS Transfer Family
Azure SFTP
Google Cloud SFTP

may expose only the SFTP subsystem without allowing remote shell commands.

Because CWP automatically attempts to execute shell commands in order to install an SSH public key, the connection fails even though SFTP authentication itself succeeds.

Expected Behaviour

The SFTP backup feature should support standard RFC-compliant SFTP servers without requiring shell access.

Ideally, CWP should:

perform a standard SFTP login;
verify read/write access using SFTP operations only;
avoid executing remote shell commands unless explicitly requested;
provide an option to disable automatic SSH key installation.
Why this matters

Many hosting providers and secure backup appliances intentionally disable shell access while still offering fully functional SFTP services.

Currently, these servers cannot be used with CWP backups even though they fully support the SFTP protocol.

Supporting pure SFTP servers would improve compatibility with modern backup infrastructures and managed storage services.

Thank you for investigating this issue.