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

P4 Server Administration Documentation | 2025.2

# Warnings, notes, and limitations

The following warnings, notes, and limitations apply to all configurations unless otherwise noted.

- On target servers The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'., do not reconfigure these replica settings while the replica is running:

  - `P4TARGET`
  - `dm.domain.accessupdate`
  - `dm.user.accessupdate`
- Be careful not to inadvertently write to the replica’s database. This might happen by using an `-r` option without specifying the full path (and mistakingly specifying the current path), by removing db files in `P4ROOT`, and so on. For example, when using the `p4d -r . -jc` command, make sure you are not currently in the root directory of the replica or standby in which `p4 journalcopy` is writing journal files.

- Large numbers of `Perforce password (P4PASSWD) invalid or unset` errors in the replica log indicate that the service user has not been logged in or that the `P4TICKETS` file is not writable.

  In the case of a read-only directory or `P4TICKETS` file, `p4 login` appears to succeed, but `p4 login -s` generates the "invalid or unset" error. Ensure that the `P4TICKETS` file exists and is writable by the replica server.

- Client workspaces on the target server and replica servers cannot overlap. Users must be certain that their `P4PORT`, `P4CLIENT`, and other settings are configured to ensure that:
  - Files from the replica server are not synced to client workspaces used with the target server.
  - Files from the target server are not synced to client workspaces used with the replica server.

- Replica servers maintain a separate table of users for each replica; by default, the `p4 users` command shows only users who have used that particular replica server. (To see the target server’s list of users, use `p4 users -c`).

  The advantage of having a separate user table (stored on the replica in `db.user.rp`) is that after having logged in for the first time, users can continue to use the replica without having to repeatedly contact the target server.

- All server IDs must be unique. Manually-assigned names might be easy to remember, but in very large environments, there might be more servers than is practical to administer or remember. Use the command `p4 server -g` to create a new server specification with a numeric Server ID. Such a Server ID is guaranteed to be unique.

  Whether manually-named or automatically-generated, it is the responsibility of the system administrator to ensure that the server ID associated with a server’s `p4 server` form corresponds exactly with the `server.id` file created (and/or read) by the `p4 serverid` command.

- Although replicas can be chained together as of Release 2013.1, (that is, a replica’s `P4TARGET` can be another replica, as well as from a central server), it is the administrator’s responsibility to ensure that no loops are inadvertently created in this process. Certain multi-level replication scenarios are permissible, but pointless; for example, a forwarding replica of a read-only replica offers no advantage because the read-only replica will merely reject all writes forwarded to it. If you are considering a multi-level replica installation, contact Perforce Support for guidance.

- The `rpl.compress` configurable controls whether compression is used on the target-replica connection(s). This configurable defaults to `0`. Enabling compression can provide notable performance improvements, particularly when the target server and replica servers are separated by significant geographic distances.

  Enable compression with: p4 configure set fwd-replica#rpl.compress=1

Your search for returned results