Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.2

# Users

There are three types of P4 Server users: `standard` users, `operator` users, and `service` users. For details about these user types, including how to create users of these types, see Types of users in the p4 user command of P4 CLI Reference.

For information about authenticating users and granting them access, see Secure the server.

By default, P4 Server creates a new user whenever a previously unknown user invokes any command that can update the repository or its metadata Information that P4 Server maintains, such as who created file revisions in the depot, whether the file is a 'lazy copy,, the current state of client workspaces, protections, groups, users, labels, streams, and branches. Metadata is stored in the server database and is separate from the 'archive files' that users submit from their client workspace into the depot.. When executed by a nonexistent user, most P4 Server commands cause a user to be created. You can control this behavior by setting the `dm.user.noautocreate` configurable with the `p4 configure` command. For security, we recommend that only the P4 Server superuser be allowed to create new users.

`p4 configure set dm.user.noautocreate=2`

## Renaming users

You can use the `p4 renameuser` command to rename users. The command renames the user and modifies associated artifacts to reflect the change: the user record, groups that include the user, properties that apply to the user, and so on. See the description of the `p4 renameuser` command in the P4 CLI Reference. In general, the user name is not changed in descriptive text fields such as change descriptions. It is only changed where the name appears as the owner or user field of the database record.

For best results, follow these guidelines:

- Before you use this command, check to see that the new user name does not already exist. Using an existing name might result in the merging of data for the existing and the renamed user despite the best efforts of the system to prevent such merges.
- The user issuing this command should not be the user being renamed.
- The user being renamed should not be using the server when this command executes. After the command completes, the user should log out and then log back in.

- The `p4 renameuser` command does not process unloaded workspaces: all the user’s workspaces should be reloaded (or deleted) first.

  A distributed installation might contain local workspaces or local labels owned by the user. These workspaces and labels, which are bound to edge servers, should be deleted or moved to the commit server first.

- Files of type +k which contain the `$Author$` tag that were submitted by the user will have incorrect digests following this command. Use `p4 verify -v` to recompute the digest value after the rename.

## Deleting obsolete users

Each standard user on the system consumes one P4 Server license. A P4 Server administrator can free up licenses by deleting users with the following command:

    $ p4 user -d -f username

Before you delete a user, you must first revert (or submit) any files a user has open in a changelist. If you attempt to delete a user with open files, P4 Server displays an error message to that effect.

Deleting a user frees a P4 Server license but does not automatically update the group and protections tables. Use `p4 group` and `p4 protect` to delete the user from these tables.

## Reverting files left open by obsolete users

If files have been left open by a nonexistent or obsolete user (for instance, a departing employee), a P4 Server administrator can revert the files by deleting the client workspace specification in which the files were opened.

As an example, if the output of `p4 opened` includes:

    //depot/main/code/file.c#8 - edit default change (txt) by jim@stlouis

you can delete the `stlouis` client workspace specification with:

    $ p4 client -d -f stlouis

Deleting a client workspace specification automatically reverts all files opened in that workspace, deletes pending changelists associated with the workspace, and any pending fix records associated with the workspace. Deleting a client workspace specification does not affect any files in the workspace actually used by the workspace’s owner; the files can still be accessed by other employees.

Your search for returned results