fajkovic.sasa

@d3fc0n0wltraps Welcome :)

Hey @PandaSharp - I've added a "Summary" level for logging which will reduce it significantly. Choose that :)

Glad the dry run worked and have high hopes the real run will also work :)

Hey @PandaSharp let me know how it goes when you give it a shot :)

Thanks @d3fc0n0wltraps — glad it's replaced the rclone setup. Not a Custom Tab bug and not really fixable on my side: Custom Tab's "Built-In Page" mode copies the body of the selected .page file into a new tab. UnraidRsync.page is only a tab container (Unraid xmenu), so its body is intentionally empty — the seven real pages are separate files. Putting content in the container would add a phantom eighth tab to the normal Settings page, so I'd rather not. Two ways that already work: 1. Use Custom Tab's URL mode with a relative URL: /Settings/UnraidRsync It's same-origin, so it works via IP, hostname or proxy without re-login and doesn't depend on the proxy being up. (Unraid only allows framing from the same origin, which is why the full proxy URL only worked when you were browsing through the proxy.) 2. Or pick the individual pages from the Built-In dropdown — they're listed under their own names: "Overview", "Jobs", "Connections", "Credentials", "Global Settings", "Status", "History" (all unraid.rsync/UR.*.page). One nav tab per page. Option 1 is probably what you want.

Hey @PandaSharp , I've just merged https://github.com/sasa-fajkovic/unraid-rsync/pull/140 Latest release: https://github.com/sasa-fajkovic/unraid-rsync/releases/tag/2026.09.04 This now adds rsync daemon support that you can choose as a transport layer on top of SSH You can select it per job and/or per connection level giving you granularity if needed :) Hope this helps and you will now have everything working nicely. In your case, probably the thing to do is create a connection using rsyncd then define: Name - whatever you wanna call the connection. Asustor NAS for example Host - IP of your NAS device Username - the module user from the NAS "Rsync Server" page, not the SSH account Module secret - it's password. Leave blank if the module has no auth users

Hi @PandaSharp — thanks for the write-up with all the details. The screenshots and both logs made this easy to pin down, and they've led to two changes in the plugin. PS, forum is fine, no need to move to GitHub. Short version: nothing is broken, but the plugin can't do what your LuckyBackup task is doing. One field has the wrong kind of value in it. WHY IT FAILED There are two different rsync protocols: host:/path rsync over SSH (port 22) <- what this plugin speaks host::module rsync daemon / rsyncd <- a separate protocol, port 873 Look closely at your own LuckyBackup screenshot: "Remote module" is ticked and the "ssh" box is NOT ticked. So despite SSH being enabled on the NAS, LuckyBackup isn't using it at all — it's talking to the rsync daemon: rsync ... --password-file=/luckybackup/p pandasharp@HOST::rsync_bkp /mnt/user/data/downloads/ Note the double colon. "rsync_bkp" there is the name of a Backup Module on your Asustor — not a folder. This plugin only speaks rsync-over-SSH, so it builds a single colon: pandasharp@HOST:/rsync_bkp Over SSH there are no modules, so rsync looks for a literal directory called /rsync_bkp on the NAS. There isn't one, which is exactly what it told you: rsync: [sender] link_stat "/rsync_bkp" failed: No such file or directory (2) Your diagnosis was right, by the way — that field does want a real path. Adding the leading slash just didn't turn a module name into one. THE FIX Your Asustor screenshot already has the answer: module rsync_bkp points at /Download/rsync_dir. That folder is what the job should target. You just need its full path as SSH sees it, which on ADM usually sits under a volume prefix. 1) From an Unraid terminal, find the real path: ssh pandasharp@HOST 'grep -A3 "\[rsync_bkp\]" /etc/rsyncd.conf; ls -d /volume*/Download/rsync_dir /share/Download/rsync_dir 2>/dev/null' The "path =" line in rsyncd.conf is the authoritative answer. 2) Prove it before touching the plugin — this is a dry run, it changes nothing: rsync -n -rtv pandasharp@HOST:/volume1/Download/rsync_dir/ /mnt/user/data/downloads/ Substitute whatever step 1 gave you. Once you see a file list, that's your path. 3) In the job, keep Transport = SSH and Direction = Pull, and change only the right-hand box of the pair: left (local) /mnt/user/data/downloads/ right (remote) /volume1/Download/rsync_dir/ <- the real path Your connection needs no changes — "Connection succeeded" already proves SSH login and password auth work against your NAS. WHAT I CHANGED BECAUSE OF YOUR REPORT — release 2026.09.02 Two things, both out now. Update the plugin to get them. 1. The remote path field is no longer silent about this. A module name, a host::module, an rsync:// address, or a pasted host:/path now each get a message explaining what the field actually wants, instead of failing on the first run with that link_stat error. A single top-level path like /rsync_bkp still saves (it's a legal path — /data and /backup are real remote paths for other people) but now warns that it may be a module name. The source/destination pairs row also gained proper help text explaining which box is which — it had none. 2. New option: "Remote rsync path (SSH jobs)" (--rsync-path), in the rsync options of a job and in Global Settings. You may well need this one. rsync-over-SSH requires the rsync binary on the NAS side, and appliances often keep it somewhere that isn't on the PATH you get from a non-interactive SSH login. If step 2 above gives you "rsync: command not found" or "remote command not found" instead of a file list, that's what's happening — run ssh pandasharp@HOST 'which rsync || ls /usr/bin/rsync /usr/local/bin/rsync' and put the answer in that field. Before this release there was no way to set it. ON DAEMON SUPPORT You're right that the plugin can't do host::module at all, and that was a deliberate scope decision rather than an oversight. But you're the second person to arrive here from a NAS whose UI only offers an "Rsync Server" toggle, so I've opened a tracking issue for proper rsync daemon transport: https://github.com/sasa-fajkovic/unraid-rsync/issues/139 I won't promise a date — it's a third transport with its own auth model, not a flag. The SSH route above should get you running tonight in the meantime. Let me know how step 1 goes, and if the path turns out to be somewhere unexpected on

Hi @NodeCentral — thanks for the detailed write-up and the screenshots. There are two separate things going on here, and one of them is my bug, not yours. 1. Port 873 is a different protocol. What you enabled in HBS 3 ("Rsync Server", port 873) is the rsync daemon protocol — rsync://host/module. This plugin does rsync over SSH, which is a completely different transport. With 873 in the Port field the plugin ran ssh -p 873; your QNAP's rsync daemon accepted the TCP connection, didn't understand SSH, and hung up. That's the "Connection closed by remote host / not running SSH" you saw. The message was technically accurate but never told you why, which is on me. The next release warns about port 873 on the Port field, on save, on Test connection, and on that exact Discover-host-key error. 2. Your command-line test was actually testing SSH, not the daemon. This one is genuinely counter-intuitive and I think it's what sent you down the wrong path: rsync 192.168.102.134:873 A single colon means "use the SSH transport", so rsync read 873 as a remote path and connected over SSH on port 22. That's why you got an ED25519 host-key prompt — it was sshd answering, not the rsync daemon. (To actually talk to the daemon you'd use rsync rsync://192.168.102.134:873/, or a double colon: rsync 192.168.102.134::.) The useful part: that prompt proves SSH is already reachable on your QNAP. So to get this working: on the QNAP, Control Panel → Network & File Services → Telnet/SSH → tick "Allow SSH connection" (port 22). Then in the plugin set the Port back to 22 and use a QNAP account permitted to log in over SSH. You can switch the HBS 3 Rsync Server back off — this plugin doesn't use it. 3. The sshpass / NerdTools message is my bug, and you're right that it's a dead end. NerdTools was archived by its authors in March 2024 and isn't available on Unraid 7, so that message was telling you to do something impossible. Password auth was effectively broken on a stock box and the plugin should never have pointed you there. I've fixed it properly rather than just rewording the message: password auth now uses OpenSSH's own SSH_ASKPASS mechanism, so it needs nothing installed at all — no sshpass, no NerdTools. The password is read from a RAM-only file created at mode 600 for the duration of the run and deleted afterwards; it never appears in a command line, an environment variable, or ps. (It's actually a small security improvement on the old sshpass approach, where the path to that file sat in the process arguments and was visible to any local user via ps.) That's merged shortly and will be in the next release. Key auth is still what I'd recommend where you have the choice, but password auth will simply work. Fix merged here: https://github.com/sasa-fajkovic/unraid-rsync/pull/137 and a new release is here: https://github.com/sasa-fajkovic/unraid-rsync/releases/tag/2026.08.31a Thanks again for reporting both — the second one in particular caught a real regression affecting everyone using password auth, not just you.

@d3fc0n0wltraps - Thank you for the feedback. Give me a day or two and will look into adding this as well :) edit: - Added support for -O/--omit-dir-times and -J/--omit-link-times as part of release https://github.com/sasa-fajkovic/unraid-rsync/releases/tag/2026.08.07. You can update the plugin and it will work. edit2: Fixed the bug - A custom Secrets directory setting made the plugin save your SSH keys to the new location but the Credentials/Connections/Jobs pages kept looking for them in the old default spot — so they appeared to vanish even though they were safely saved; fixed in the release https://github.com/sasa-fajkovic/unraid-rsync/releases/tag/2026.08.07d @d3fc0n0wltraps - I did e2e tests and works now properly. Let me know the feedback from your side.

Unraid Rsync is a native webGui plugin for scheduling and monitoring rsync backup jobs — either over SSH to/from a remote host, or locally between two paths on the server. Unlike the existing single-schedule rsync plugins, this is a multi-job scheduler: each job gets its own cron schedule, its own source→destination pairs, and its own rsync options. GitHub: https://github.com/sasa-fajkovic/unraid-rsync Install URL: https://github.com/sasa-fajkovic/unraid-rsync/releases/latest/download/unraid.rsync.plg Why I built this I wanted to back up music, appdata, a Nextcloud install, and an Immich library to a remote Raspberry Pi over SSH — each with different schedules, different rsync flags, and pre/post hooks (stopping a database container before the transfer, starting it again after) while having proper integration with Unraid and it's notification system. None of the existing plugins covered multi-job + per-job hooks + per-job flag overrides in one place, so I built this one. What it does - Multiple independent jobs, each with: - Transport: SSH (push/pull to a remote host) or Local (paths on this server, under /mnt) - Its own cron schedule (not one global schedule), with a live "Next run" column - A curated, whitelisted set of rsync flags as checkboxes/inputs (no free-form flag string — destructive flags are gated), each with inline help on hover - Explicit source → destination pairs (one rsync call per pair, not a cartesian product of multiple sources × destinations) - Pre/post hooks (run as root, output captured into the per-run log) - Per-job log level and notify mode (off / success-only / failure-only / always) - Live state badges (success/warning/failed/aborted/pending/running) and a per-run log viewer that polls live while a job is running - Manual Run / Dry-run / Abort per job — dry-run before you trust anything unattended - A Connections tab for reusable SSH endpoints (existing key file, managed key, or password via sshpass), with host-key discovery and a connection test - A Credentials tab — a managed SSH key keychain (generate or import) - Status tab showing the rolling plugin log + an rsync-binary presence check - Notifications through Unraid's native notify system - Clean uninstall (removes both the runtime tree and the persistent /boot config, clears cron lines) Screenshots Install Requires Unraid 7.0.0+. 1. Plugins → Install Plugin 2. Paste: https://github.com/sasa-fajkovic/unraid-rsync/releases/latest/download/unraid.rsync.plg 3. Click Install, then open Settings → User Utilities → Unraid Rsync Updates are automatic via Plugins → Check for Updates — releases use CalVer and publish automatically on every merge to main. A note on credential security Credentials are stored on the USB flash /boot/config/plugins/unraid.rsync/credentials.json), which is FAT32 and world-readable — Unix permissions don't apply there. To keep things safe by default: - Existing-key-file auth (the default) never copies your private key into the plugin's store — only the path is recorded. - Managed keys are only ever decrypted to RAM (tmpfs, mode 600) at run time, and the private key is never shown again in the UI after saving. - Password auth is stored obfuscated, not encrypted — use key auth where possible, and a low-privilege remote account if you must use a password. This is documented up front in the README rather than buried, since it's a backup tool handling credentials. Status Feature-complete for my own use case (appdata / Nextcloud / Immich → remote Pi over SSH with DB stop/start hooks), running nightly. Not yet in Community Applications — submitting once this thread exists, since CA wants a forum support link in the .plg. Bugs / feature requests: https://github.com/sasa-fajkovic/unraid-rsync/issues Feedback welcome, especially on the credential-storage approach and anything that looks unsafe before more people start pointing this at real backups.