remote transfers - degoya/rDownloader GitHub Wiki

FTP, SFTP and WebDAV

rDownloader downloads from FTP, FTPS, SFTP and WebDAV servers natively — no external client. A directory is reviewed as a file tree before anything is queued, and each selected file becomes its own queue row, so it resumes and retries on its own.

Credentials and SSH host keys are managed under Settings → FTP, SFTP, WebDAV & S3 → FTP, SFTP & WebDAV.

Supported schemes

Scheme Protocol
ftp:// FTP
ftps:// FTPS — explicit (AUTH TLS) and implicit (port 990)
sftp:// SFTP over SSH
webdav://, dav:// WebDAV over plain HTTP
webdavs://, davs:// WebDAV over HTTPS

The secure and insecure aliases are never silently swapped for one another. If you ask for dav://, you get plain HTTP.

WebDAV files download over the ordinary HTTP engine, so they get parallel chunks, resume, authentication profiles, proxy, custom CA and the bandwidth limits like any HTTP download.

A public Nextcloud or ownCloud share

Such a share is not a server login: paste the …/s/<token> address and the folder is listed with its names, sizes and subfolder structure, the shared folder's own name suggesting the package. A share protected by a password takes it as the part of the address after a # — …/s/<token>#password — and a wrong one says so instead of reporting an empty folder.

A protected share is not an account but an authentication profile (under Settings → Accounts → Site logins), scoped to that host and the share's path — never to a whole host — with the password stored encrypted. The password appears in no link, API answer or log line.

Credentials

Settings → FTP, SFTP, WebDAV & S3 on its FTP, SFTP & WebDAV tab, beside S3: the form for a stored login and the saved servers, each with Test, edit and delete

Settings → FTP, SFTP, WebDAV & S3 → FTP, SFTP & WebDAV. A stored login is keyed on server, port and user, has a Test action, is stored encrypted and is never returned by any API. A stored password or key stays with the server it was entered for: when an edit changes the protocol, the host or the port, the form says so and asks for it again before saving. Every create, edit and delete of a login is recorded in the audit log, never with a password or key.

SFTP authenticates with a password, a private key (with an optional passphrase), or an SSH agent. An SFTP login always names its user; one without a user name is refused (sftp.no_username) rather than tried as root.

Credentials pasted into a link

A link of the form ftp://user:password@host/… is accepted, because that is how such a location is normally shared. What happens then:

  • The credential is stored encrypted, once.
  • The link is rewritten to its bare form before it reaches the queue, an event or a log line.
  • An existing login for the same server and user is never silently overwritten.

SSH host keys

An SSH host key is confirmed once by a person and stored per server, port and algorithm.

  • An unknown server is blocked, showing its SHA256: fingerprint so you can compare it.
  • A server whose key later changes is blocked, showing both fingerprints, and is never accepted automatically: a rebuilt server and an intercepted connection look the same.

Optional first-use trust exists for unattended setups. It is off by default and covers only a first sighting — it never accepts a changed key.

Browsing and queueing

A directory listing is presented as a file tree with folder tri-state selection. Pick what you want; each selected file becomes its own queue row.

Resume

Resume is validated, not assumed. Size and modification time are recorded on the first attempt and rechecked before continuing. If either moved, the partial file is kept and the transfer is refused rather than corrupted.

  • An FTP server that refuses REST, or a WebDAV server without Accept-Ranges, reports that a restart would be needed instead of silently appending to what is already on disk.
  • A transfer that ends early fails instead of promoting a truncated file into the destination.
  • Weak ETag validators (W/"…") are ignored; the resume check falls back to size and Last-Modified.

Hardening

FTPS trusts the platform certificate store augmented by your custom CA. A CA bundle that parses to nothing is refused rather than falling back to the public roots.

WebDAV listings from a hostile server cannot reach outside the requested folder: every entry must lie inside it and on the same origin, and entity expansion and oversized answers are refused.

Server replies never reach the queue verbatim, since they often quote user names and remote paths; failures carry stable ftp.*, sftp.* and webdav.* codes that the interface translates.

Settings

Concurrent transfers and the connect/login/read timeout are configurable on the same page. All transfers honour the scoped bandwidth limits.

Uploading

This page is about downloading from remote servers. Uploading finished packages to a remote destination is a post-processing step — see Post-processing and the bundled webdav-storage plugin in Bundled plugins.

Switching remote transfers off

Settings → Services → Remote file transfer. Matching links are refused at intake and anything queued moves to Blocked.

Related pages

⚠️ **GitHub.com Fallback** ⚠️