Perforce Public Knowledge Base - Common Permissions and File Access Problems
Reset Search
 

 

Article

Common Permissions and File Access Problems

« Go Back

Information

 
Problem

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


Solution
Perforce 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 and client workspace mappings are typically configured either via the command line with the P4 client (using the p4 protect command and the p4 client command, respectively), or a Perforce visual client (P4Admin and P4V, respectively).

Triggers are typically configured via the command line the command line with the P4 client, using the p4 triggers command

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.

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 the following error:
You don't have permission for this operation.
or:

protected namespace - access denied.

or:

no permission for operation on file(s).
To determine what protections are 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 View 

Typical errors include:
//depot1/... - must refer to client 'clientname'.
or:

Mapping '//depot1/...' is not under '//depot2/...'.
or:
file not under client's root
or:

/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:
/perforce/workspace

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:
/perforce/workspace/depot/... 
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

Feedback

 

Was this article helpful?


   

Feedback

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

Characters Remaining: 255