filex

Overview ¶

client.go wires the `filex client` subcommand family — a CLI consumer of a REMOTE filex server's REST API (the rest of the binary manages a local instance). Connection resolution, wire calls and mv semantics live in internal/cliclient; this file is cobra plumbing + rendering (client_files.go holds the queue-backed and per-file extras).

client_files.go - the `filex client` commands that reach the operations queue and the per-file extras: cp (and mv's multi-source form), trash, versions, tag, actions/run, archive, and share ls|rm. The wire calls live in internal/cliclient; this file is cobra plumbing and rendering.

client_plugins.go — `filex client plugins request|requests`: leave a plugin install request and follow it (docs/APP-PLUGINS.md → Install requests). An API key cannot install a plugin; an administrator approves or rejects the request in the admin panel, and there is deliberately no command for that.

Command filex is the self-hosted file-manager binary.

Default behavior (`filex` with no args) is to start the HTTP server. All subcommands accept --config /path/to/config.yaml (or FILEX_CONFIG env).

filex serve                                 # default
filex migrate up | down | status
filex admin reset-password [--email]
filex admin random-password [--email]
filex storage list | add | remove
filex thumb backfill [--storage <id|name>] [--limit N] [--retry-failed]
filex client login | ls | upload | download | mkdir | rm | mv | search | share
filex e2e-escrow keygen                      # install-time E2E key escrow
filex decrypt <folder|zip|file> [-o DIR]     # offline: decrypt a downloaded E2E folder
filex vault mount|prune adapter://vault      # a vault (E2E level 3) on a server
filex plugin-validator --spool DIR           # an app store's storage plugin conformance runner
filex --version

mount.go wires the `filex mount` subcommand: a remote filex server, attached to a folder on this machine.

It is the third answer to "let me use filex as a drive", and the one that works from anywhere: NFS needs a LAN, SFTP needs sshfs or WinFsp installed and configured, and this needs the same HTTPS and the same session token the web app already uses. Authentication, ACLs, the tenant scope and reach through whatever proxy sits in between all come for free, because underneath it is the REST API.