Initially, a Determined installation has two user accounts:
determined. Both of
these accounts have blank passwords by default.
admin user has the sole privilege to create users, change other users’ passwords, and
det user change-password via the CLI to set a password for the
admin user. This is
highly encouraged for new installs.
det -u admin user change-password
determined user is designed for ease of use on a single-user installation. However, teams
will benefit from creating a Determined user account for each individual. Namely, having individual
user accounts provides clearer authorship and improved filtering of entities. To create users in a
Determined installation, use the
admin user to create user accounts for each individual that
would like to use Determined:
det -u admin user create <username>
determined user can be deactivated:
det -u admin user deactivate determined
This ensures that no one can access the Determined cluster as the
determined user (any objects
that were created by this user will remain).
The WebUI will automatically redirect users to a login page if there is no valid Determined session established on that browser. After logging in, the user will be redirected to the URL they initially attempted to access.
A browser Determined session can be ended by clicking “Sign Out” under the user menu in the top right of the WebUI.
In the CLI, the
user login subcommand can be used to authenticate a user:
det user login <username>
Logging in results in a persistent session, which lasts for 30 days. The session can be terminated using:
det user logout
In some cases, it may be useful to execute a single command as a specific user without starting a
persistent session for that user (think of the
sudo command on a Unix-like system). In
Determined, this can be achieved with the
det -u <username> ...
This will execute the command as the given user without creating a permanent session for that user.
Although no persistent session is created, an authentication token is stored for that user so that
future attempts to execute commands as that user will not require re-authenticating. This token can
be discarded using the
user logout subcommand:
det -u <username> user logout
Users have blank passwords by default. This might be sufficient for low-security or experimental
clusters, and it still provides the organizational benefits of associating each Determined object
with the user that created it. If desired, a user can change their own password using the
det user change-password
An admin can also change another user’s password:
det -u admin user change-password <target-user>
Although Determined supports password-based authentication, communication between the CLI, WebUI, and master does not take place over an encrypted channel by default. See Security for information on configuring secure connections over HTTPS. Users should not be assigned “valuable” passwords, and passwords used with Determined should not be reused for other purposes.
Just as in the CLI, by default the WebUI will only show assets created by the current user. To see assets belonging to all users, uncheck the “Show only mine” checkbox in the filter panel found in the tab for each asset type.
When using the CLI to list experiments, commands, etc., the default behavior is to only show assets
belonging to the current user. It is possible to show assets owned by all users by passing the
-a flag to the respective commands:
det experiment list -a # List all experiments. det command list -a # List all commands. det notebook list -a # List all notebooks. det tensorboard list -a # List all TensorBoards.
Activate and Deactivate Users¶
When a user is created, they are designated as active by default. Only active users can interact
with Determined. The
admin user can deactivate a user with the
user deactivate subcommand:
det -u admin user deactivate <target-user>
All assets created by a deactivated user will remain available through both the WebUI and the CLI.
To reactivate a user,
user activate can be used:
det -u admin user activate <target-user>
Run Tasks as Specific Agent Users¶
If an experiment, notebook, or command task uses the
bind_mount option in its
Experiment Configuration Reference, it is often useful to set the Unix user and group on the agent
that the task runs as. This allows the file permissions on the agent to be reflected in the task and
This can be configured by linking a Determined user with the user and group configuration on an agent:
det user link-with-agent-user <target-user> --agent-uid <uid> --agent-user <username> --agent-gid <gid> --agent-group <group-name>
All arguments are required. This command can only be run by a system administrator.
Once set, any tasks created by the target user will be run as the specified user and group.
By default, if a user is not linked with a user and group on an agent, tasks created by that user will run as the root user on the agent. This behavior may change in the future.
If the task does not use
bind_mount option, the effect of running as root will be limited to
the task container and not intrude on the agent itself.
The default user and group that will be used when a Determined user is not explicitly linked to a
user and group on an agent can be configured in the
master.yaml file located at
/usr/local/determined/etc on the Determined master instance:
security: default_task: user: root uid: 0 group: root gid: 0
Run Unprivileged Tasks by Default¶
Some administrators of Determined may wish to run tasks as unprivileged users by default. In Linux,
unprivileged processes are sometimes run under the nobody user, which has very few privileges. However,
nobody user does not have a writable
HOME directory, which causes problems for some
common tools like
For convenience, the default Determined environments contain an unprivileged user named
det-nobody, which does have a writable
HOME directory. The
det-nobody user is a suitable
default user when using the default Determined environment images and when running containers as
root is not desired. To use
det-nobody by default, add the following configuration to
security: default_task: user: det-nobody uid: 65533 group: det-nobody gid: 65533
When combining the
det-nobody user with custom Docker images, administrators should either build
the custom image as layers on top of the default Determined Environments as illustrated in
Custom Images, or they should create the
det-nobody user themselves in their
custom images using