Determined is designed for teams of machine learning developers. Any entity (such as an experiment or a notebook) is visible to all users on the same installation of Determined, regardless of who created it.
Initially, a Determined installation has two user accounts:
determined. Both of these accounts have blank passwords by
admin user has the sole privilege to create users, change other
users’ passwords, and activate/deactivate users.
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
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
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
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
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
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
user change-password subcommand:
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.
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.
Just as in the CLI, by default the WebUI will only 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 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>
Running tasks as particular agent users¶
If an experiment, notebook, or command task uses the
option in its Experiment Configuration, 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 vice
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
master.yaml file located at
the Determined master instance:
security: default_task: user: root uid: 0 group: root gid: 0
Running 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, the
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
user themselves in their custom images using