This page answers common questions about MaxCompute permission management.
Authorization solutions
How do I read data across projects?
Use packages. A package bundles objects from one project and lets other projects install and access them — the primary mechanism for cross-project authorization in MaxCompute. The workflow is:
-
A project administrator packages the required objects and sets permissions on them.
-
Other projects install the package.
-
Administrators of those projects manage the installed package and grant access to their own users.
For details, see Access resources across projects based on packages and Permission control for packages.
Can the project owner be changed to a RAM user?
No. The project owner is permanently set to the account that created the project and cannot be transferred. If you need a Resource Access Management (RAM) user to have broad administrative control, the project owner can grant that RAM user the Admin role.
The Admin role provides extensive administrative capability but excludes four operations that only the project owner can perform. See What can't the Admin role do that the project owner can?.
What can't the Admin role do that the project owner can?
The Admin role has full day-to-day administrative access, but four operations are reserved for the project owner:
| Capability | Project owner | Admin role |
|---|---|---|
| Assign the Admin role to other users | Yes | No |
| Modify the project's security configuration | Yes | No |
| Modify the project authorization model | Yes | No |
| Modify Admin role permissions | Yes | No |
Tip: To reduce operational risk, avoid using the project owner account for routine tasks. Create a dedicated user with the Admin role for daily administration, and use the project owner account only for the four operations listed above.
A RAM user cannot access DataWorks and is prompted that an AccessKey ID is missing, but the AccessKey ID exists. How do I solve this issue?
A RAM user must add their AccessKey information to their personal profile. Go to the Personal Information page. Click Modify AccessKey Information and enter the AccessKey ID and AccessKey Secret. After the configuration is complete, try to access DataWorks again.
Granting permissions
A RAM user can't access DataWorks and is prompted that an AccessKey ID is missing. How do I fix this?
The RAM user needs to add their AccessKey information to their personal profile. Go to the Personal Information page, click Modify AccessKey Information, and enter the AccessKey ID and AccessKey Secret. After saving, try accessing DataWorks again.
Authorization fails when I grant a RAM user access to a production table. How do I fix this?
Symptom
The following error appears when you grant permissions on a production table:
class java.lang.IllegalArgumentException: AccessId should not be empty.
Cause
The AccessKey ID and AccessKey Secret are not configured for the account performing the grant.
Solution
Log on to the RAM console as the Alibaba Cloud account or RAM user performing the authorization, and confirm that the AccessKey ID and AccessKey Secret are configured.
How do I grant a user permissions on a table?
Only the project owner or a user with the Super_Administrator or Admin role can perform authorization. Use the access control list (ACL) GRANT command:
GRANT UPDATE ON TABLE project_name TO ram$bob@aliyun.com:Allen;
For the full list of grantable permissions and objects, see MaxCompute permissions.
How do I grant permissions to a RAM user?
Authorization must be performed by an Alibaba Cloud account or a user with the Super_Administrator or Admin role. For more information about authorization, see MaxCompute permissions.
What are subjects, objects, and actions in MaxCompute authorization?
MaxCompute authorization is built around three elements:
-
Subject: The user or role receiving permissions.
-
Object: The resource being protected — a project, table, model, function, resource, or instance.
-
Action: The operation permitted on that object, such as reading, writing, or querying.
For more information, see ACL-based access control.
How can a RAM user access a project owned by a different Alibaba Cloud account?
Say Account A has a RAM user (ram_user_1) that needs access to a project owned by Account B. The steps are:
-
Account B adds Account A to the project and grants Account A the Super_Administrator role.
-
Account A logs on to Account B's project and runs the following command to add ram_user_1:
add user ram$A:ram_user_1;
How do I get my tenant ID?
-
Log on to the MaxCompute console and select a region in the upper-left corner.MaxCompute console
-
In the left navigation pane, choose Manage Configurations > Tenants.
-
On the Tenants page, click the Tenant Property tab.
-
Copy the value shown for Tenant ID.
Error: "FAILED: Invalid account Name xxxxxx"
FAILED: Invalid account Name xxxxxx
Cause
The username in the GRANT statement is misspelled or in the wrong format.
Solution
Run list users; to retrieve the exact usernames in the current project, then copy the username directly from the output into your authorization command.
Error: "FAILED: lack of account provider, principalName xxxxxx"
FAILED: lack of account provider, principalName xxxxxx
Cause
The project's account system does not support RAM, or the username is in the wrong format.
Solution
-
Check whether the project supports RAM:
list accountproviders; -
If
ramis not in the output, add it:add accountprovider ram; -
Run
list accountproviders;again to confirm RAM is now listed. -
If the error persists after RAM is added, the username itself may be wrong — run
list users;and copy the exact username into your command.
Permission errors
I have permission to query a view, but the query fails with a permission error about another user. Why?
Cause
The query fails because the view owner — not you — is missing the SELECT permission on the underlying table. In MaxCompute, views are evaluated using the owner's permissions. If the owner loses access to a referenced table (for example, after a view ownership change or an explicit permission revoke), the view becomes unavailable to everyone, even users who have been granted query access to the view.
Solution
Check the view owner's grants:
show grants for <view_owner_username>;
If the SELECT permission on the referenced table is missing, re-grant it to the view owner. The view will then work again.
Error: "You have NO privilege to do the restricted operation on xxx Access Mode is AllDenied"
You have NO privilege to do the restricted operation on xxx Access Mode is AllDenied
Cause
The project is disabled.
Solution
Check either of these causes:
-
Overdue payment or expired subscription quota: Add funds to your account or renew the subscription. The project is automatically restored to Normal state, which can take 2 to 30 minutes depending on the number of orders and projects involved.
-
Manually disabled: In the MaxCompute console, go to Manage Configurations > Projects and resume the project.
Error: "failed to check policy format: invalid Action value - odps:\<Action\>"
Symptom
When you use the policy authorization feature to create a role named test_role for the Resource type and grant the CreatePackage permission to the role, you write the following policy:
{
"Statement":[
{
"Action":[
"odps:CreatePackage"
],
"Effect":"Allow",
"Resource":[
"acs:odps:*:projects/test_project/authorization",
"acs:odps:*:projects/test_project/authorization/packages/*",
"acs:odps:*:projects/test_project/authorization/packages/*/*/*"
]
}
],
"Version":"1"
}
The following error is returned:
Create role test_role error: [400] com.aliyun.odps.OdpsException: failed to check policy format: invalid Action value - odps:CreatePackage
Cause
This error occurs when you assign a project management permission (such as CreatePackage) to a role of the Resource type. MaxCompute does not allow project management permissions on Resource-type roles.
Solution
Switch the role type to Admin (management type) when the custom role needs to include project management permissions. For a full list of project management permissions, see List of project management permissions. For role planning guidance, see Role planning.