APPID
, SecretId
, and SecretKey
?The second half of a bucket name is the APPID
. You can view it by logging in to the COS console. To view information such as SecretId
and SecretKey
, log in to the CAM console and go to the Manage API Key page.
Currently, a temporary key can be valid for up to 2 hours (i.e., 7,200 seconds) for the root account, and 36 hours (i.e., 129,600 seconds) for a sub-account. The default validity period is 30 minutes (i.e., 1,800 seconds). Requests carrying an expired temporary key will be denied. For more information, please see Generating and Using Temporary Keys.
SecretId
and SecretKey
is compromised?You can delete the compromised key and create a new one. For more information, see Access Key.
You can set the effective time for your key by referring to Generating and Using Temporary Keys.
You can grant such permission by referring to Setting Folder Permissions. To grant more advanced permissions to a sub-account, see Authorization Cases.
You can use the diagnostic tool provided by the COS team, which uses RequestId
to troubleshoot errors.
BucketName
, APPID
, Region
, SecretId
, and SecretKey
is correct.In most cases, this error is reported due to unauthorized access or insufficient permissions. You can troubleshoot as follows:
BucketName
, APPID
, Region
, SecretId
, and SecretKey
is correct. Note that you should also check whether spaces are carried.The COS team provides the diagnostic tool, which uses RequestId
to troubleshoot errors.
Each root account (i.e., each APPID
) can have up to 1,000 bucket ACLs. If more bucket ACLs have been configured, an error will be reported. Therefore, you are advised to delete unnecessary ACLs.
Note:You are not advised to use file-level ACLs or policies. When calling APIs or SDKs, if you do not need ACL control over a file, we recommend leaving the ACL-related parameters (such as x-cos-acl and ACL) empty to inherit the bucket permissions.
Possible causes:
The following two solutions are provided for your reference:
Solution 1: Set the access permission of an existing bucket to private read/write and try creating a bucket again. For more information, see Setting Access Permission.
Solution 2: In Permission Policy Settings, click Add Policy and configure access permissions as needed. For more information, please see Adding Bucket Policies.
If you use an expired signed URL to access a public-read file, COS will first verify the permissions. If the URL has expired, the access will be denied.
You can troubleshoot as follows:
BucketName
, APPID
, Region
, SecretId
, and SecretKey
is correct.The COS team provides the diagnostic tool, which uses RequestId
to troubleshoot errors.
You can prevent users from downloading data based on your use case as follows:
deny anyone Get Object
in the bucket policy.Assume that you (root account A) need to grant bucket permissions to the sub-account B0 that is under the root account B. You need to first grant the root account B permissions to operate your bucket. Then, root account B should grant the permissions to its sub-account B0. For detailed directions, see Granting Bucket Permissions to a Sub-Account that is Under Another Root Account.
You can log in to the CAM console to create a custom policy that grants specified permissions to sub-accounts. For detailed directions, please see Creating Custom Policies.
Note:When creating the custom policy, you need to grant read permissions, set upload only for write operations, and do not grant delete permissions.
You can set a permission to deny anyone's Get Bucket operation for the bucket by following the steps below:
Log in to the COS console, click Bucket List, click the desired bucket, and select Permission Management.
Click Permission Policy Settings. Then, click JSON > Edit and enter the following code:
{
"Statement":[
{
"Action":[
"name/cos:GetBucket",
"name/cos:GetBucketObjectVersions"
],
"Effect": "Deny",
"Principal":{
"qcs":[
"qcs::cam::anyone:anyone"
]
},
"Resource":[
"qcs::cos:ap-beijing:uid/1250000000:examplebucket-1250000000/*"
]
}
],
"version": "2.0"
}
Note:Replace values in
qcs::cos:ap-beijing:uid/1250000000:examplebucket-1250000000/*
with the actual information as follows:
- “ap-beijing”: Replace it with the region where your bucket resides.
- “1250000000”: Replace it with your
APPID
.- “examplebucket-1250000000”: Replace it with your bucket name.
The second half of the bucket name is the
APPID
. You can view it by logging in to the COS console.
ACLs are account-specific. You are not advised to use file-level ACLs or policies. When calling APIs or SDKs, if you do not need ACL control over a file, we recommend leaving the ACL-related parameters (such as x-cos-acl and ACL) empty to inherit the bucket permissions.
A collaborator is a special sub-account. For more information, please see Access Policy Language Overview.
You can log in to the CAM console to go to the User Management page, where you can create sub-accounts for different services and grant different permissions for them.
You can create sub-accounts and grant them permissions by referring to Granting Sub-accounts Access to COS.
To grant a sub-account access to a specific bucket, you can add a bucket policy for the sub-account with the root account. For more information, see Adding Bucket Policies.
For more information, see FAQs.
You can troubleshoot by referring to Resource Access Error.
This is usually because the CDN acceleration domain is disabled. You can troubleshoot by referring to “HTTP ERROR 403” Is Returned When I Access COS Using a CDN Domain.
This is usually because of the existing cache. You can troubleshoot by referring to A URL Points to a Wrong File.
If you need authentication when CDN pulls from COS with files set to private read/write, see Setting CDN Acceleration.
Was this page helpful?