Backup restoration doesn't work: "Restore" button disappears after selecting a zip file

[finnvyrn]

To Reproduce

Back up Dokploy to S3 (I use B2) without specifying a prefix.

Remove the docker swarm services created by Dokploy:

docker service remove dokploy dokploy-traefik dokploy-postgres dokploy-redis
docker container remove -f dokploy-traefik

Remove the docker volumes created by Dokploy:

docker volume remove -f dokploy dokploy-postgres dokploy-redis

Restore it.

Current vs. Expected behavior

After selecting the last Zip file, the "Restore" button disappears.

If I use the previous "Restore" button, available when selecting the directory, the log shows:

Provide environment information

OS: Arch Linux x86_64
Kernel: Linux 7.0.0-1-cachyos
AMD64
Dokploy Version v0.29.2

Which area(s) are affected? (Select all that apply)

Installation

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

No response

Will you send a PR to fix it?

No

[dosubot]

This looks like it stems from a few validation gaps in the restore flow. Here's what I found in the code:

Why the "Restore" button disappears: The restore button's disabled logic is commented out in the UI component, which paradoxically causes issues with how the form state interacts with directory vs. file selection. When you click a directory, the UI appends a trailing slash to navigate into it, and when you then select the zip file inside, the form state transition may not properly re-render the button.

Why the unzip fails when using the directory-level Restore: The backend restoreWebServerBackup function has no validation to check whether the selected path is a directory or a file. It uses rclone copyto to download the path from S3, then runs unzip on it [1]. When a directory path is passed instead of a zip file, rclone downloads the directory structure, and unzip fails because it's operating on a directory, not a zip archive. The error is also partially masked because unzip output is redirected to /dev/null 2>&1, suppressing stderr.

Additional context: Recent PRs (#3934, #3919) reorganized S3 backup storage paths into a hierarchical appName/prefix/filename structure, which introduced more directory navigation in the restore UI—making it easier to hit this bug.

A few things that could fix this:

• Frontend: Un-comment and enhance the disabled button logic to reject directory paths (e.g., paths ending with / or selections where IsDir is true)
• Backend: Add validation in restoreWebServerBackup to confirm the path is a file before downloading
• Backend: Remove 2>&1 from the unzip command so errors are actually visible in the logs

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[finnvyrn]

I'm sorry. I was using night mode, so I didn't see the bottom horizontal scroll bar. After scrolling it, I can see the Restore button now and it worked!

When the filename is too long, it's required to horizontally scroll it first to see the button.

I'd suggest always show the Restore button even if the filename is too long.