Skip to content

v0.50.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 03 Oct 01:02
· 47 commits to main since this release
v0.50.0
This tag was signed with the committer’s verified signature.
brkfun Burak Faruk ŞAHİN
GPG key ID: A8FEBA97FF786513
Verified
Learn about vigilant mode.
9873e3e

filex v0.50.0

Self-hosted file manager - Go single binary + multi-framework frontend.

Download a binary below, or pull a Docker image:

docker pull ghcr.io/brf-tech/filex:slim-v0.50.0
docker pull ghcr.io/brf-tech/filex:full-v0.50.0

What changed

⚠ Desktop app on Linux: Chromium's sandbox is no longer optional
(Security). On Ubuntu 23.10 and later (24.04 LTS included) an
AppImage needs a one-time AppArmor profile before it opens, and says so when
it is missing - including an AppImage added to the menu by AppImageLauncher,
Gear Lever or appimaged, whose entry used to turn the sandbox off. The Snap
asks snapd for the sandbox: until the Snap Store connects that by itself
(it reviews the permission by hand, so the new revision can wait for the
review before it reaches stable), run
sudo snap connect filex-app:browser-sandbox once; the app says so too. The
.deb and the .rpm need nothing
(DESKTOP.md).

⚠ LDAP: an entry with no e-mail attribute is name@local now
(Changed). An account an older filex opened under the bare name
(alex) is adopted at that person's next sign-in - web or file protocol -
and becomes alex@local (alex@<realm>.local in a tenant's realm on a
multi-tenant install): the same account, its files, shares, permissions,
role and quota unchanged, with an audit row auth.account_adopted. A local
password on it is kept; an account bound to SSO is signed in to as it is,
not renamed. Nobody is refused and nothing is left to do by hand. Set
FILEX_OS_LOGIN_EMAIL_TOKEN before upgrading if local is not the
token you want - it cannot be changed later. On a multi-tenant install only
an account in the sign-in's own tenant is adopted: one in another tenant is
left alone and the platform operator is told once
(ldap_legacy_account_elsewhere), so re-home the directory accounts an older
build left in the supertenant before upgrading. A file-protocol sign-in says
which tenant it is for by its address or by realm/name; one that names
nothing is the platform's own and adopts nothing (or pin provider)
(LDAP.md).

⚠ Multi-tenant: on the platform's address an empty realm is the platform's
own tenant (Added, tenant realms). A tenant's people who used to
sign in there with their e-mail alone type their tenant's realm in the new
Realm field - or sign in on their tenant's own address, where the field is
filled in for them. Over SFTP (and FTPS with no SNI, and WebDAV on the
platform's address) they write realm/name.
Existing tenants' realms are their slugs; an API token or an SSH key needs no
realm. Single-tenant installs are unaffected.

⚠ Multi-tenant on SQLite or PostgreSQL: two tenants whose slugs differ only
in case stop the upgrade. Migration 00073 gives every tenant the realm
LOWER(slug) under a unique index, so Acme and acme cannot both have
one: the migration fails and the server does not start until one of them is
renamed (MySQL's default collation never let such a pair exist). Look
before upgrading, and change one slug while still on 0.49:
SELECT LOWER(slug), COUNT(*) FROM providers GROUP BY LOWER(slug) HAVING COUNT(*) > 1;. The realm is copied once and never changes after
that
(MULTI-TENANCY.md → Realms).

⚠ Multi-tenant: sign-in providers are bound to tenants now
(Added, tenant self-service). The upgrade binds every provider
that exists (OIDC, LDAP, the proxy header, Windows, Linux PAM, environment
and page alike) to every tenant that exists, which is what happened
before: one directory served every tenant. Review the bindings on Admin →
Identity providers (the page says so until you have) and remove the tenants
a provider should not serve. A provider added after the upgrade serves the
platform's own tenant only, and a tenant created after it has no shared
provider until one is bound. FILEX_LDAP_PROVIDER / FILEX_HEADER_PROVIDER
keep working and count as a binding to the pinned tenant. A tenant's own
OIDC on its provider row is unchanged. Single-tenant installs read no
bindings (TENANT-ADMIN.md).

⚠ SSO: which account a sign-in opens (Security). An OIDC
sign-in finds its account inside the tenant it is for only, by the SSO
identity the account is bound to (iss + sub), and by the email address
only while the account is bound to none - and then only when the provider
says email_verified: true or its addresses are trusted. On upgrade:

  • Every OIDC provider that exists keeps its old behaviour: its new
    setting Trust this provider's email addresses comes on, and its card
    says the upgrade set it. Switch it off on a provider that sends
    email_verified. A provider added after the upgrade starts with it off.
    The environment's OIDC follows FILEX_OIDC_TRUST_EMAIL; unset, it trusts
    when the database had accounts that came through SSO (decided once, at
    the first start of 0.50), and not on a fresh install.
  • With trust off, an unverified address opens no existing account that is
    bound to no identity yet (email_unverified), and a new account for it is
    opened switched off (account_pending): switching it on in Admin →
    Users approves it.
  • An account is bound to the identity it first signs in with. Changing
    the identity provider, or its issuer address (a renamed Keycloak realm),
    refuses its accounts     (identity_mismatch) until each account's SSO
    bind is removed (Admin → Users → Remove SSO bind, sso_unlink).
  • Multi-tenant: an SSO callback that comes back without its flow cookie is
    refused (expired); a sign-in in flight during the upgrade starts again.
    A tenant's account signing in through OIDC in maintenance mode gets the
    generic answer now, not maintenance.
    (SSO.md)

⚠ A forwarded client address is believed only from a trusted proxy now
(Changed, FILEX_TRUSTED_PROXIES). Up to 0.49 every
X-Forwarded-For was believed, whoever wrote it. The default is auto,
worked out from where filex runs: this machine (loopback) and, in a
container on a network of its own (Docker, Podman, a Kubernetes pod), the
other containers on that network - never the network's gateway, never
filex's own address, never the LAN, never a macvlan or ipvlan network. A
proxy container next to filex, and a proxy on the same machine as a plain
install, need nothing. A proxy on the host in front of filex's container
(nginx reaching a port published on 127.0.0.1 arrives from the Docker
gateway), a proxy on another machine, an ingress controller on another
Kubernetes node, a proxy that reaches filex over 100.64.0.0/10 (Tailscale,
Cloudflare WARP) and a CDN in front of your proxy must be listed, keeping
the word - FILEX_TRUSTED_PROXIES=auto, 172.18.0.1. Until they are, every
visitor resolves to the proxy's address: the access log, the audit log, the
file-request limit and the new sign-in limit all see that one address, and
one visitor's wrong passwords lock out everybody who arrives through it.
Admin → Sign-in security names such a proxy - a peer that sends
forwarded addresses without being trusted - and adds it in one click; the
log names it too. Helm: list the cluster's pod network
(trustedProxies: "auto, 10.244.0.0/16"). Clients on a LAN that reach
filex with no proxy in front need nothing set
(CONFIGURATION.md → Trusted proxies).

⚠ Apps and storage plugins are downloaded from public addresses only
(Security). An app installed from an address or a repository,
an install request, the update check and a storage plugin from a URL or a
source now refuse an address on this machine, on the private network or of
the cloud metadata service - judged after DNS and on every redirect - and a
redirect from https:// to plain http://. An administrator who installed
from an internal server is refused now: upload the files instead (an app
installed that way earlier says Could not check at the update check).
FILEX_PLUGIN_LOOPBACK_SOURCES=1 opens this machine, and nothing else, for
development and tests - never on a server
(CONFIGURATION.md).

⚠ Storage plugins (Security): a plugin keeps the driver
name it was first accepted with - another plugin may not take it, even while
the first is off; a remote plugin that answers with a redirect is refused
(register the address it points to); and a share download goes straight to a
plugin's presigned address only when that address is https://.

⚠ The bundled S3 server is Versity S3 Gateway, not MinIO (Changed).
minio/minio is no longer published, so a Compose stack or Helm release that
bundled MinIO copies its bucket across once: the versitygw Compose profile
and versitygw.enabled in Helm replace minio, and MinIO's own data format
is not readable by the new server. Nothing is deleted for you: Compose keeps
the minio-data volume, and the chart refuses to render while
minio.enabled is true, with the commands that keep the old volume and
MinIO serving while you copy
(STORAGE.md → Moving off the bundled MinIO).

⚠ LibreOffice is gone: office conversions and thumbnails need a connected
ONLYOFFICE (Changed, Removed). The full image
drops LibreOffice and its Java runtime (about 420 MB less to download and
1.1 GB less on disk: 642 → 225 MB compressed), and filex no longer runs a
LibreOffice installed next to the bare binary either. Office documents are
the ONLYOFFICE Document Server's you connect under External services:
their thumbnails, and the apps' office engine - the Convert app's Word,
Excel, PowerPoint and OpenDocument conversions, PDF/A included. With
ONLYOFFICE connected there is nothing to do: the engine uses the editor's
address, secret and callback address and turns on without a restart, and
the thumbnails LibreOffice drew before are kept and drawn again by
ONLYOFFICE, one document at a time, as they are listed (or all at once with
a Fix repair). Without it, office documents show their type icon instead
of a thumbnail and the Thumbnail repair tab says "ONLYOFFICE is not
configured", the converter's office targets are greyed for an administrator
with "connect it under External services", and a job that asks anyway says
so - nothing fails silently; documents still open in the read-only preview
and + New still makes them. An app that asks for engines:libreoffice
keeps working: it is the same engine as engines:office, and the same
grant. ONLYOFFICE does not make HTML from a spreadsheet or one CSV per
sheet, as LibreOffice did
(ONLYOFFICE.md,
thumbnails.md → Office through OnlyOffice).

⚠ A page on another origin that changes things with filex's session cookie
needs that origin in FILEX_CORS_ALLOWED_ORIGINS (Security).
The default * does not grant it, and a page on a sibling subdomain is
another origin too. An embed with a bearer token, a host that proxies with a
key (the recommended pattern), the desktop app, the installed web app, a
dashboard that frames filex, share and drop links, upload tickets, WebDAV and
S3 clients, and scripts are unaffected. A refused change answers
403 cross_origin_refused.

Also on upgrade:

  • The operating-system providers (windows, pam) are switched on from
    Admin → Identity providers only, after their test. Written into
    FILEX_AUTH_DRIVERS or auth.drivers, either is refused at start with a
    warning, and the other providers start as usual.
  • A link into docs.filex.sh at a heading that held a long dash has a new
    fragment (#token-kinds--user-vs-app is #token-kinds---user-vs-app);
    the old one opens the top of the right page (Changed).
  • The CLI's saved session (~/.filex/cli.yaml) is used only at the address
    it was saved with: a script that reaches the same server by another name
    or an IP signs in there once, or passes FILEX_TOKEN (Security).
  • An agent (REST /api/ai, MCP) or a ShareX setup that writes into an
    end-to-end encrypted folder is refused now (409 E2E_PLAINTEXT_REFUSED):
    pass allow_plaintext where storing plaintext there is meant
    (Security).
  • Read Security if you handed out folder-confined API tokens
    (one could change sharing grants outside its folder, on any install) or
    ran 0.49.0 multi-tenant (a tenant's administrator could rewrite the
    built-in roles), and if you run OIDC (an identity provider could sign a
    person in to another account, another tenant's on a multi-tenant install).

This release has more to it than fits on one page. The rest of the
entry - and every earlier release - is in CHANGELOG.md.

Verify: sha256sum -c checksums.txt

Assets 39
Loading