👨‍👩‍👧‍👦 Manage multiple user

Manage User

Click on your Avatar → Admin Area to navigate to your user panel.

The user panel is at the bottom of the page above the worker logs.

You can create, delete and manage users of your instance. You can change the scan path, password, name and e-mail of a given user.

Not released yet (comes after 1.4.0) The circular arrow next to a user's scan directory scans that user's library now, the same scan as the Scan button on their Library page: the job is theirs and shows in their job list. While it runs, the arrow shows its progress. So after you fix a user's scan path, you can scan it without signing in as them. On your own Library page, Change scan directories in the Admin Area under Scan library leads to this table.

Please note: In LibrePhotos, the file system acts as the definitive source of photo organization. This means that folder structure dictates how photos are grouped and accessed within the application.

To isolate users and their photo collections, create a subfolder for each user inside the folder you set as scanDirectory in your .env file — the folder LibrePhotos mounts as /data. Inside LibrePhotos these show up as /data/user1, /data/user2, etc., and that is the path you assign as each user's scan directory. Create the folders before assigning them: LibrePhotos only accepts directories that already exist under /data. This ensures that users only see and interact with the photos in their designated directories.

Not released yet (comes after 1.4.0) You can make such a folder in the user edit dialog: choose the folder it goes in, click New folder above the folder list, type its name and press Enter. The new folder is chosen as the scan directory right away. Only admins can make folders, only inside /data, and a name cannot hold / or \, be . or .., or be a name Windows refuses (such as CON or a:b). If LibrePhotos may not write to the folder, the dialog says so; then make the folder on the host.

Changing a user's scan directory

Not released yet (comes after 1.4.0) When you point a user at another folder, their photos from the old folder stay theirs: nothing moves to another user. The edit dialog counts the user's photos outside the new folder and asks what to do with them before you save:

• Keep them in the user's library (the default): nothing changes, as before.
• Move them to the user's trash: after the save, a job (Trash Photos Outside the Library, shown in the job list) moves them to the user's trash. The files on disk are not touched, and the user can restore the photos from the trash until it is emptied. The Save button turns red and says how many photos it moves.

Photos in the user's upload folder, in their further library folders and copies from their Nextcloud count as inside. If another user's scan directory holds the same files, that user's next scan adds them to their own library.

Scan directories of different users must not overlap. Every photo belongs to exactly one user, so LibrePhotos refuses a scan directory that is the same as, inside, or above another user's scan directory, and names the user it clashes with. In particular, once one user scans /data itself, no other user can be given any folder under /data, so give every user a folder of their own, the admin included. Installations that already have overlapping scan directories keep working and those users can still be edited; only changing a scan directory to one that overlaps is refused. Two users whose scan directories overlap each get their own photo of a file both scan, with its own thumbnails and face crops. New in 1.4.0 Up to 1.3.0 the second user's photo shared an internal key with the first user's, so either of them could be refused a photo of their own or see the other's rotation of it. LibrePhotos 1.4.0 repairs those photos once while it starts, copying their thumbnails and face crops, so the first start takes a little longer and the thumbnails folder grows by those copies.

If your admin account already scans /data and you want to add more users, move the admin's photos into a subfolder such as /data/admin, set that as the admin's scan directory and run a scan. The moved photos are matched to their existing entries by their content, so ratings, faces and albums are kept; see Missing Photos for how that relinking works.

Several library folders per user

Not released yet (comes after 1.4.0) A user's library can span more than one folder, for example a folder of their own and a shared family folder, or a second disk. The scan directory stays the user's main folder (uploads go below it unless an upload folder is set); further folders are added in the user edit dialog, under Library folders:

1. Open the user in the Admin Area and click Add folder under Library folders.
2. Pick a folder in the tree (or type its path) and click Add folder. It must already exist under /data.
3. Run a scan: every scan reads all folders of the library from then on.

The same list is on that user's Library page; as an admin you can add and remove your own folders there. Adding or removing a folder in the dialog applies right away, without Save.

The rules for scan directories hold for every library folder: a folder may not be the same as, inside or above a folder of another user's library (scan directory, upload folder or a further folder), and the error names the user it clashes with. Within one library, folders may not overlap either: a folder inside the scan directory is already part of the library. A scan directory that would contain one of the user's further folders is refused until you remove that folder.

Remove… in a folder's menu takes it out of the library. Its files stay on disk and its photos stay the user's, outside the library; tick Also move its photos to the user's trash to move them to the trash right after, as when the scan directory changes. The main folder cannot be removed; change the scan directory instead.

A folder that cannot be read (an unplugged disk) is shown as Not found and skipped by scans; its photos are not marked missing.

Every user can also leave subfolders out of their own library, from the Library page; see Leaving subfolders out.

To let several users see the same photos, keep the photos in one user's library and share them from there: albums and individual photos can be shared with other users on the instance, see Sharing. Sharing photos in a family compares the setups a household can use.

While the application saves metadata (e.g., tags, albums, facial recognition data) on a per-user basis in its database, it doesn’t inherently restrict access to the photos themselves. Access permissions must be managed through the file system / paths.

The separation will also not keep the photos "private" as the admin of the host system can see all the images.

Deleting a user

The red trash icon in a user's row deletes that account. Admin accounts cannot be deleted, so the icon is greyed out for them.

Deleting a user removes the account, so it can no longer sign in, but it does not remove the user's library. Their photos, albums, tags and stacks stay in the database and are handed to a disabled placeholder account called deleted, which cannot sign in and is not listed in the Admin Area. Nothing is removed from disk: the original files and their thumbnails stay where they are. If the photos should go as well, they have to be deleted from that user's library while the account still exists (see Trash).

Since 1.3.0, deleting a user also turns off everything of theirs that people without an account could open: public album links, photo links and public photos. Those links stop working for anyone who opens them. Nobody can sign in as deleted, so nobody could turn them off later. Links left on by users deleted with an older version are turned off when you upgrade to 1.3.0.

Albums and photos the user shared with other users of the instance stay shared. Those users keep seeing them, now owned by deleted. Photos that other users shared with the deleted user are taken out of the deleted user's albums, so the people those albums are shared with cannot open them later. The photos stay in their owners' libraries.

A user deleted after another one can have an album or a tag with the same name as one that deleted already holds. Two albums are never mixed into one, so nobody gets to see one user's photos through the other user's shares:

• An album the user made gets their username added to its title, for example Holiday (bob), and keeps its photos and the users it is shared with.
• A generated album (an event, a day, a place or a thing) is dropped. Its photos are kept.
• A tag is merged into the tag of the same name. Tags are not shared with anyone.

Upload folder

Photos uploaded through the web interface or backed up by the mobile app are written to an uploads folder inside the user's scan directory: /data/user1/uploads/web/. The user edit dialog in the Admin Area shows the folder uploads land in under the scan directory.

Since 1.3.0, you can put a user's uploads somewhere else: pick a folder in the Upload folder field of the same dialog. It is checked like a scan directory: it must already exist under /data, and it must not be inside, above or the same as another user's scan directory or another user's upload folder. A folder inside the user's own scan directory is fine. Uploaded photos are scanned into the uploader's library, so an upload folder counts as part of that user's files: the same rule also refuses a scan directory that is inside, above or the same as another user's upload folder, and the error names the user and whether it clashes with their library or their upload folder. As with scan directories, a value that already overlaps is kept when you save the user without changing it. Uploads then go to <upload folder>/web/. Clear the field to go back to the default.

Uploaded photos always belong to the user who uploaded them. If the upload folder is outside the user's scan directory, the photos still show up in their library, but a scan of the scan directory does not look in that folder and the folder view does not list it.

Giving each user their own folder automatically

Admin Area → Site settings has a Create a folder for each new user switch, off by default. With it on, creating a user — from the admin panel, from self registration, or through single sign-on — also creates /data/<username> and assigns it as that user's scan directory, so you no longer have to make the folder on the host and assign it by hand for every account.

It only works when your own scan directory is a subfolder such as /data/admin, not /data itself. Scan directories of different users cannot overlap (see above), so while any user scans /data, every /data/<username> folder is refused.

What it deliberately does not do:

• It never overwrites a scan directory you typed on the create form. An explicit path wins.
• It never fails account creation. If /data is read-only, the username does not name a plain folder (such as . or ..), or the folder would overlap a directory another user already scans, the account is still created — just without a scan directory — and the reason is written to the backend log. Nothing is created on disk in that case. Assign a directory by hand afterwards.
• It does not give a self-registered or single sign-on account a folder that already exists. Otherwise anyone who can sign up could take over, say, /data/family just by choosing family as their username. Such an account is created without a scan directory instead. When you create a user in the admin panel and /data/<username> already exists, that folder is assigned, since you can see what is in it.
• It does not touch existing users. Only accounts created while the switch is on get a folder.

User Registration

Click on your Avatar → Admin Area to the user registration setting.

You can also activate user registration, where user can create an account themselves. They cannot change the path, which means the admin is still in full control.

Unless Create a folder for each new user is on, a self-registered account is created without a scan directory, so the new user sees an empty library and is told to contact their administrator if they try to scan or upload. After someone signs up, open the Admin Area, edit their account in the user panel at the bottom of the page and set its scan path as described above.

How to change the admin password, when you can't log in

There are three ways to accomplish that:

• 1. If your .env sets the admin credentials, the password is reset every time the backend container starts. The keys are userName, userPass and adminEmail (passed to the backend as ADMIN_USERNAME, ADMIN_PASSWORD and ADMIN_EMAIL), and both the username and password must be non-empty. They are not in the shipped librephotos.env template, so add them yourself — see Admin account variables for the full behaviour.
• 2. If you have access to your container, you can change the password by executing a Django management command docker exec -it [backend container name] python manage.py changepassword [admin username]
• 3. If outgoing e-mail is configured on your instance, the login page shows a Forgot your password? link that e-mails a reset link to the address on your account. This only works once e-mail is set up (Admin Area → Site settings → Email) and the account has an e-mail address, so arrange both before you get locked out. Behind the bundled proxy, also set frontendBaseUrl in your .env (passed to the backend as FRONTEND_BASE_URL) so the emailed link points at your public address rather than the internal one.