Users.md

Users, Permissions, and Profiles

Fireshare supports multiple user accounts. An administrator creates them, grants each one a set of permissions, and every account gets a shareable profile page listing what they uploaded.

Permissions

Every account is either an administrator — who can do everything, including change server settings and manage users — or a regular account holding a set of individual permissions.

Permission	What it allows
view_private	See private videos and images in feeds, folders, tags, and games
upload	Upload videos and images
edit_own	Edit titles, descriptions, privacy, crops, and posters on their own uploads
delete_own	Delete their own uploads
edit_any	Edit any media, including content with no uploader
delete_any	Delete any media, including content with no uploader
manage_tags	Create, rename, delete, and assign tags
manage_games	Manage game metadata, artwork, and folder rules
transcode	Start and cancel transcoding jobs
manage_library	Use the bulk File Manager and trigger library scans

Server configuration and user management are administrator-only and cannot be granted individually — that is what keeps "administrator" a meaningful role.

Presets

The Add User dialog offers three presets. They are only shortcuts for ticking boxes; nothing about a preset is stored, so you can adjust any account freely afterwards.

Preset	Permissions
Viewer	view_private
Contributor	view_private, upload, edit_own, delete_own, manage_tags
Curator	Contributor plus edit_any, delete_any, manage_games, transcode, manage_library

Upgrading an existing install

Accounts that already existed before permissions were introduced could do everything a signed-in user could do. The upgrade grants each of them the full Curator permission set, so nobody loses access. Narrow them afterwards if you want to.

Adding users

Settings → Users → Add User (administrators only).

Choose a username, pick a preset or individual permissions, and choose how the person gets their password:

• Send a setup link (recommended) — Fireshare generates a one-time link you copy and hand over. You never see or choose their password. The link expires after 7 days and works once.
• Set a password now — you type an initial password. The account is flagged to require a change at next sign-in.

Fireshare has no mail server, so setup links are copied from the dialog rather than emailed.

Usernames may contain letters, numbers, dots, dashes, and underscores, must be 2–32 characters, and must start and end with a letter or number. A short list of reserved names (admin, api, settings, and similar) is rejected because they would collide with a URL or read as a system account.

Passwords

Anyone can change their own password under Settings → Security. Changing it requires the current password.

An account created with a password an administrator typed is asked to replace it the first time it signs in, before the rest of Fireshare becomes available.

An administrator can reset someone's password, or issue a fresh setup link, from Settings → Users. An administrator can also clear a stuck two-factor enrollment there — the same recovery the fireshare disable-mfa command performs.

Profiles

Every account has a profile page at /u/<username> showing what they uploaded, their upload counts, and total views. The link renders Open Graph metadata, so it previews properly when pasted into Discord or similar.

What a visitor sees:

• Anyone with the link sees only that account's public uploads. Private media stays link-only, exactly as it does everywhere else in Fireshare.
• The account owner always sees their own private uploads on their profile.
• Other signed-in users need view_private to see someone else's private uploads.

view_private governs discovery — the feeds, folder and tag listings, game pages, and profiles. It does not change what a share link does: private media stays link-only, so anyone holding a link to one item can still open that item.

Users can set a display name, a short bio, and a profile picture from Edit profile on their own page. Turning off Share my profile page makes the page return "not found" to visitors; individual video and image share links keep working.

Profile pictures are re-encoded to a 256×256 WebP on upload. Only the decoded image survives, which strips camera metadata and makes it impossible to hide anything in the file. Accounts with no picture get a lettered placeholder in a colour derived from the username.

Uploads show a clickable uploader byline on the main video and image pages, which links to that person's profile.

Media ownership

Videos and images record who uploaded them. Ownership is what makes edit_own and delete_own meaningful.

On upgrade, everything already in the library is attributed to the administrator account — the one ADMIN_USERNAME manages. Nothing in the old schema recorded who uploaded what, and on the single-admin install that describes most upgrades the administrator is the accurate owner. Reassign anything that belongs to someone else from File Manager → Uploader; the upgrade prints how many items it attributed.

Files a library scan finds on disk are attributed to that same administrator account as they are indexed. Nothing on the server's own filesystem can say who put it there, and the person who runs the server is the one who did, so the administrator is the accurate owner; hand anything that belongs to someone else to them from File Manager → Uploader. Uploads made while signed in belong to the account that made them.

Media has no uploader when it was:

• uploaded through the public (unauthenticated) upload form, or
• had its uploader deliberately cleared.

Unowned media appears on no profile, and edit_own / delete_own deliberately do not grant access to it — only edit_any / delete_any do. Otherwise every account with "own uploads only" access would implicitly control the entire pre-existing library.

Deleting a user never deletes their media. The uploader link is cleared and the content stays in the library as unowned.

Adopting existing content

To give a pre-existing library an owner, select files in File Manager and use Uploader. Pick an account to attribute them to, or "No uploader" to clear the link again. Once attributed, the media appears on that person's profile and comes under their edit_own / delete_own permissions.

Guardrails

Fireshare refuses, server-side, to:

• remove administrator access from the last enabled administrator,
• disable or delete the last enabled administrator,
• let anyone disable, delete, or demote their own account,
• demote or delete the account managed by ADMIN_USERNAME / ADMIN_PASSWORD, since startup would reinstate it on the next restart.

Disabling an account ends its access immediately, including any active session and any "remember me" cookie.

LDAP has been removed

LDAP authentication is gone. Every account is a local account.

To make sure the change is never a surprise, Fireshare refuses to start while any LDAP_* variable is still set, and it does this before touching the database. Removing those variables is how you confirm the upgrade:

LDAP has been discontinued
---------------------------------------------------------------------
LDAP authentication has been removed from Fireshare in this version
and all later versions. This instance still has an LDAP
configuration, so Fireshare has not started and your database has
not been modified.

Remove the variables from your compose file and start Fireshare again. On that first start, each directory account is converted to a local account:

• Uploads, profile, display name and permissions are kept. Nothing is deleted, and every account keeps its database id, so media stays attributed to whoever uploaded it.
• The account has no password, so it cannot sign in yet. Set one, or send an invite, from Settings → Users.
• Administrator status is left exactly as it was at that account's last sign-in. It used to be re-derived from LDAP_ADMIN_GROUP on every login; now it is an ordinary flag you manage yourself. Worth reviewing once after the upgrade, since it is no longer maintained for you.

If you still depend on a directory server, do not remove the variables. Pin your image to the release you were running before the upgrade and stay there.

Command line

# Create a non-admin account with the Contributor preset (the default)
fireshare add-user -u alice

# Create an administrator
fireshare add-user -u bob --admin

# Create an account with specific permissions
fireshare add-user -u carol --permissions upload,edit_own,delete_own

# Review who exists and what they can do
fireshare list-users

# Two-factor lockout recovery
fireshare disable-mfa -u alice

Note: add-user now creates non-admin accounts by default. Before permissions existed it created administrators, because the underlying admin flag defaulted to true. Pass --admin if you want the old behaviour.