Perforce Public Knowledge Base - Common Permissions and File Access Problems
Downloads Blog Company Integrations Careers Contact Try Free
Menu Search
Reset Search



Common Permissions and File Access Problems

« Go Back



I'm receiving errors related to permissions and file access issues in Perforce.


Perforce P4 file access errors are usually related to one of these three things:

  • The protections currently in place (as configured in the protections table).
  • The current client workspace mapping (as configured in the client workspace specification).
  • Triggers currently in use (as configured in the triggers table).

Protections, client workspace mappings and trigger definitions can be managed from the command line with the p4 client using p4 protect, p4 client and p4 triggers respectively.

Client workspaces can also be configured using the Perforce Visual Client (P4V), and protections within the Perforce Administration client (P4Admin).

For more information on configuring protections and triggers, see the System Administrator's Guide.

For more information on configuring client workspaces, see the P4 User's Guide or the P4V Online Help.

Note: In this article, we focus on using the command line.

Perforce Protections Table

If the permissions defined in the Perforce protections table don't allow you to perform a particular operation, you might see one or more of the following errors:

You don't have permission for this operation.
protected namespace - access denied.
no permission for operation on file(s).

To determine the protections currently in effect for a specific user, run the command:

p4 protects -u username

This command produces output similar to:

list group all_users * -//...
write user username * //depot/foo_project/...

In the above example, we see that the user is a member of the group "all_users", which removed all access to the Perforce server. They are re-granted access to the "foo_project" branch. This would explain a permissions issue if they attempted to sync to "//depot/bar_project/...". If needed, make changes by editing the protections table as a super user:

p4 protect

Note: Perforce reads the protection table from the top down, and then from the bottom up to check for exclusionary mappings-- views prefaced with a minus sign ("-"). Perforce best practice is to have all "super" protections listed at the bottom of the protect table to avoid accidentally locking super users out due to those exclusionary protections. Contact Perforce Support if you accidentally lock super users out of Perforce.

Note: If you are performing an integration, confirm that you have permissions to the integration target directory.

For more information on editing the protections table in Perforce, refer to the "Administering Perforce: Protections" chapter of the Perforce System Administrator's Guide.

Client Workspace Views

Typical errors include:

//depot1/... - must refer to client 'clientname'.
Mapping '//depot1/...' is not under '//depot2/...'.
file not under client's root
/perforce/workspace/foo.c - file(s) not in client view.

To inspect the client workspace view, run the following command:

p4 client -o clientname

Check the "View" lines in the client workspace specification to confirm that the file specification used in your Perforce command (or appearing in the error message) falls within your workspace view. If you see an error attempting to add a file, for example, you might want to check your mapping to confirm that the file resides in a directory that is within your client view.

If needed, change the client workspace by running:

p4 client -o clientname

For example, a user attempts to add this file to Perforce:

p4 add /perforce/workspace/foo.c

They see the error:

/perforce/workspace/foo.c - file(s) not in client view.

They look at their workspace client specification (named "a_client"), and see that the "Root" is set to:


And their mapping is:

//depot/...   //a_client/depot/...

Since the client name in the right hand side of the view is treated as a shortcut for the root, we see that the full workspace path for all files in the depot is:


Since the file, foo.c, is not under the "depot" directory, Perforce notes that the file is not within the client view. Moving the file into the "depot" directory (or appropriate sub-directory) will correct the problem.

Trigger-related Issues

If you see a "validation failed" error, then a Perforce trigger is involved. For example:

'triggername' validation failed: no error message

To resolve this error, first check that the trigger is defined correctly by running the command:

p4 triggers -o

and finding the entry for the trigger name listed in the error message.

Next, use the indicated command and arguments (from the p4 triggers -o output) to run the trigger script from the command line as the Perforce user that runs the trigger. Correct any errors that you see.

If the trigger script runs without errors from the command line but has errors in the triggers table, check:

  1. The path in the trigger table is correct.
  2. Paths with spaces are enclosed by quote marks.
  3. The Perforce user that runs the trigger is logged in.

To confirm that a user is being logged in, you can add this debug code to the script:

p4 login -s 2>&1

If the user is still logged in on the trigger machine, the output from this code would be similar to:

User username ticket expires in hour hours min minutes

Otherwise, you would see the message:

Your session has expired, please login again.

Correct this by logging in the Perforce user for the trigger to the trigger host:

p4 -u username login

Files made writable by .NET

An unusual case is when a user finds the synced files always writeable in the workspace. One case we know about is when properly Perforce Bind'ed Visual Studio files get synced on to a client where no Perforce SCC Plug-In is installed. In this case, .NET automatically makes these files writeable. At some point in this process, .NET shows a few prompts that informs the Perforce user that the SCC integration is not present. If the user ignores these warnings, .NET silently removes Read-Only files attributes. This can make this whole experience confusing.

Related Links



Was this article helpful?



Please tell us how we can make this article more useful.

Characters Remaining: 255