All Products
Search
Document Center

MaxCompute:FAQ about permission management

Last Updated:Mar 26, 2026

This page answers common questions about MaxCompute permission management.

Category Questions
Authorization solutions How do I read data across projects? · Can the project owner be changed to a RAM user? · What can't the Admin role do that the project owner can?
Granting permissions A RAM user can't access DataWorks and is prompted that an AccessKey ID is missing. How do I fix this? · Authorization fails when I grant a RAM user access to a production table. How do I fix this? · How do I grant a user permissions on a table? · How do I grant permissions to a RAM user? · What are subjects, objects, and actions in MaxCompute authorization? · How can a RAM user access a project owned by a different Alibaba Cloud account? · How do I get my tenant ID? · Error: "FAILED: Invalid account Name xxxxxx" · Error: "FAILED: lack of account provider, principalName xxxxxx"
Permission errors I have permission to query a view, but the query fails with a permission error about another user. Why? · Error: "You have NO privilege to do the restricted operation on xxx Access Mode is AllDenied" · Error: "failed to check policy format: invalid Action value - odps:\<Action\>"

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:

  1. A project administrator packages the required objects and sets permissions on them.

  2. Other projects install the package.

  3. 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:

  1. Account B adds Account A to the project and grants Account A the Super_Administrator role.

  2. 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?

  1. Log on to the MaxCompute console and select a region in the upper-left corner.MaxCompute console

  2. In the left navigation pane, choose Manage Configurations > Tenants.

  3. On the Tenants page, click the Tenant Property tab.

  4. 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

  1. Check whether the project supports RAM:

    list accountproviders;
  2. If ram is not in the output, add it:

    add accountprovider ram;
  3. Run list accountproviders; again to confirm RAM is now listed.

  4. 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.