Files.fm WebDAV and FTP / FTPS

These protocols expose Files.fm files and folders. They are separate from REST V2, DVS records, and the CalDAV/CardDAV calendar server.

WebDAV

Setting	Value
Public base URL	`https://webdav.files.fm/`
Authentication	HTTP Basic with the canonical Files.fm username and password, or a compatible User Access Token in the Basic password field
File paths	Discover with `PROPFIND`; percent-encode path segments and preserve returned `href` values
Resource formats	DAV XML metadata and raw file bytes

Use the WebDAV host directly. REST API hashes are not WebDAV file paths. A folder add/delete key or MCP Bearer token is not a DAV Basic credential. The DAV authenticator checks APP-compatible tokens and accepts ALL; an API-only or FTP-only key must not be assumed compatible. Account/IP policies and password-based 2FA can affect login.

Discover the root and its immediate children:

curl --user 'YOUR_USERNAME' --max-time 30 -i -X PROPFIND \
  'https://webdav.files.fm/' -H 'Depth: 1' \
  -H 'Content-Type: application/xml; charset=utf-8' --data-binary @- <<'XML'
<d:propfind xmlns:d="DAV:"><d:prop><d:displayname/><d:resourcetype/>
<d:getcontentlength/><d:getetag/><d:getlastmodified/></d:prop></d:propfind>
XML

curl prompts for the password/token. A 207 Multi-Status response must be parsed with namespace-aware XML and per-resource/per-property statuses; it does not mean every item succeeded. Avoid recursive Depth: infinity discovery. Read files with GET; conditional writes use the returned ETag and If-Match.

The SabreDAV filesystem backend implements folder/file operations, permissions, and locking. Use LOCK/UNLOCK and lock tokens when a DAV client requires them. PUT, MKCOL, MOVE, COPY, DELETE, and LOCK can change persisted state; test against a dedicated account, not arbitrary production files. Limits and version handling follow the underlying Files.fm account and file operations.

Network-drive setup covers OS/client mounting. Client support is not proven merely by a server accepting DAV methods.

FTP and explicit FTPS

Setting	Value
Public hosts	`ftp.files.fm`, `ftp.failiem.lv`
Control port	`21`
Recommended mode	Explicit TLS (`AUTH TLS`), protected data connection, passive mode
Username	Canonical Files.fm username
Password field	FTP User Access Token generated in account settings (`FTP` or `ALL` type)

Use explicit FTPS, not implicit TLS on port 990 or SFTP/SSH. The PHP FTP service authenticates an access token; the account password is not the documented FTP login credential. Plain FTP is only appropriate for devices that cannot use TLS, with a dedicated isolated account and awareness that credentials/data are unencrypted.

Configure a compatible FTP client with passive transfers and TLS protection for both control and data channels. The repository daemon config has passive ports 50000–51000; operators must verify the actual deployment/firewall range before providing network allow-list instructions. Do not hard-code a data port in an integration.

Paths are filesystem paths discovered using FTP listing, not REST hashes. Uploads, renames, and deletes use the same underlying Files.fm file operations and access rights. Verify the client's resume, overwrite, and concurrent-transfer behavior before using it for backup workflows. Command availability is advertised by the server's FEAT response; do not assume every FTP extension exists.

Implementation and verification boundaries

DAV/FTP do not expose DVS tasks, clients, or projects as structured records. Use the DMS API for those integrations. General protocol semantics: SabreDAV, WebDAV RFC 4918, FTP TLS RFC 4217.