How to Set Up Multiple User Accounts on Haiku

Haiku contains a real user/group database and commands such as useradd, passwd, su, and login. Those facilities support service identities and limited POSIX shell scenarios. They do not currently turn a standard Haiku installation into a family-style multi-user desktop with a login chooser, isolated Tracker/Deskbar sessions, one independent settings tree per person, and safe graphical fast-user switching.

This distinction is a security boundary, not wording. If the goal is separate private desktops for several people, stop here and use an operating system that officially provides that model. The steps below are appropriate only for controlled service or shell testing.

Audit the installed model first

In a normal Haiku desktop session, inspect the current identity and account commands:

whoami
id
useradd --help
passwd --help
su --help

The default interactive identity is normally named user and historically has UID 0 privileges. Confirm the output on the actual release instead of assuming Linux defaults. Haiku’s own su source describes user as the equivalent of root.

Read the current filesystem-layout documentation too. Haiku exposes a shared /boot/home, with the user’s writable settings under ~/config. The official application guide still describes the mirrored home hierarchy in terms of when Haiku becomes multi-user aware. That is strong evidence that account database entries and a complete graphical multi-user desktop are separate stages.

Take a backup before changing the account database. Record current IDs with id and save the exact test objective, account name, desired UID/GID behavior, home path, shell, and cleanup plan.

Understand what `useradd` actually implements

The current Haiku source documents these useradd options: -d home, -e expiration, -f inactive days, -g primary group, -s shell, and -n real name. It assigns a free UID starting at 1000 and defaults the home field to /boot/home, primary GID to 100, and shell to /bin/sh.

Crucially, Haiku’s command does not implement Linux’s -m option and does not create a home directory. Therefore this old-looking command is wrong on Haiku:

useradd -m newusername

Likewise, the tree contains Haiku-specific group tools, but Linux recipes such as usermod -aG ... should not be assumed valid; usermod is not part of the current multiuser command source directory. Always use each installed command’s help and Haiku documentation/source.

Create a disposable shell test identity

Choose a unique, non-sensitive name. Do not use an identity expected by an installed service. For an intentionally shared-home shell experiment:

useradd -n "Disposable shell test" -d /boot/home -s /bin/sh labuser
id labuser

This creates an account record. It does not create a new desktop, copy default preferences, or provision private data. Leaving /boot/home as the home field means the test identity points at the existing shared home hierarchy.

Set a password only if the planned authentication path requires one:

passwd labuser

Use a unique test password and never publish it in notes or shell history. A password does not add a boot-time graphical login screen. If a network login service is enabled, it may also make the account reachable according to that service’s configuration, so audit listening services and firewall/network exposure first.

Verify the identity in a shell

Switch only for the controlled test:

su -l labuser
id
whoami
pwd
exit

The current Haiku su supports -l for a login shell and -c for a command. Confirm that effective UID/GID changed and that the environment/home are what the account record declares. Do not launch Tracker, Deskbar, or arbitrary native GUI applications and call the result a second desktop session; application-server integration and per-user desktop state are not supplied by this exercise.

For a service account, follow that service’s current Haiku-specific guide/package configuration. Choose the least-capable shell and filesystem access that the service actually supports, and start it through Haiku’s service mechanism. Do not create a login password or interactive shell merely because a generic Linux tutorial does so.

Test POSIX permissions without overstating isolation

Nonzero-UID processes can exercise normal owner/group/other permission checks. In a disposable directory, create files under the test identity and inspect them from another nonprivileged service identity if one is available. Record id, ownership, group, mode, and the exact process context.

However, the normal desktop runs under the privileged user identity. UID 0 can bypass ordinary discretionary access controls and change ownership/modes. Therefore a directory owned by labuser is not private from the person operating the default Haiku desktop.

Packagefs adds another important distinction: packaged /boot/system content is a virtual package view, not a conventional directory made writable by chmod or chown. POSIX permission experiments cannot replace package installation, activation, or the documented non-packaged hierarchy.

Do not manufacture a fake second home

It is technically possible to put another path into an account’s home field and manually create a directory. That alone does not make bundled applications, Deskbar, Tracker, packagefs home packages, settings servers, MIME database, launch services, and application-server connections form an independent desktop.

Avoid symlink tricks that swap /boot/home, bulk chown of the shared hierarchy, edits to package-managed paths, or boot scripts that pretend to select a user. They can strand settings, weaken security, or make package state unrecoverable without delivering a supported login model.

If the practical requirement is lending the computer, use a separate device/OS session designed for guests. If it is data-at-rest privacy, use supported encryption and physical-access controls rather than account entries. If it is isolating a network daemon, use its documented service identity and minimize privileges.

Remove the test cleanly

Before deletion, stop every process running as the account and inventory files it owns. Do not blindly delete all files returned by an ownership search; UID reuse or intentional shared data can make that destructive.

Review the installed command’s help, then remove the disposable account using Haiku’s supplied tool:

userdel --help
userdel labuser

Verify id labuser no longer resolves and separately handle only the test files you positively identified. Deleting an account record does not guarantee that service files, logs, or manually created directories disappear.

Define success honestly

Success for this procedure is a nonzero-UID account that can run the intended shell command or documented service, is constrained as tested, and can be removed cleanly. It is not a second secure graphical user profile.

Recheck the official release notes and Haiku source when revisiting this topic; multi-user integration can evolve. Until the project documents a supported GUI login/session workflow, use the account commands for their proven POSIX/service scope and keep shared-computer security expectations conservative.

Related:

Sources: