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, please 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, please see Cases of Permission Setting.
You can use the COS debugger that the COS team developed for developers to configure Hosts to capture COS API requests and intelligently analyze the error in the requests. You can also troubleshoot the error according to the following process:
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.You can also use the COS debugger that the COS team developed for developers to configure Hosts to capture COS API requests and intelligently analyze the error in the requests. The tool will provide the error details and handling suggestions.
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.
This is because your bucket is set to public read/private write, or public read/write. These permissions occupy the number of ACLs your root account is allowed to use. This error is reported because the root account has used up the number of ACLs allowed, which cannot be adjusted.
The following two solutions are provided for your reference:
Solution 1: Set the access permission of the bucket to private read/write. For more information, please 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.You can also use the COS debugger that the COS team developed for developers to configure Hosts to capture COS API requests and intelligently analyze the error in the requests. The tool will provide the error details and handling suggestions.
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, please see Granting Sub-account Under One Root Account Permission to Manipulate Buckets 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 inqcs::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 access paths for the sub-account. For more information, see Accessing Bucket List Using a Sub-account.
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, please see CDN Origin-Pull Authentication.
Was this page helpful?