This topic describes the causes and solutions for common errors you may encounter when you use the OSS SDK for Python.

Failed to upload parts by using the OSS SDK for Python.

Failed to upload data to OSS by using the multipart upload function provided by the OSS SDK for Python, and a large number of parts are generated.

  • First, determine whether the object is directly uploaded to OSS or uploaded to OSS through other proxies such as CDN. If the object is uploaded to OSS through CDN, the ETag of the object must be exposed and the following items must be configured for OSS: HTTP header, Access-Control-Allow-Origin, Access-Control-Allow-Mehtods, and Access-Control-Allow-Headers. For more information, see PutBucketCORS.
  • If the upload failed because of timeout, we recommend that you use resumable upload to upload the object. By using resumable upload, you can upload object parts concurrently and customize the part size. When the OSS SDK returns an exception, view and analyze the exception information in detail.
  • Delete the parts generated by the failed upload task and upload the object again.
If the problem persists, provide the following information by sending a ticket:
  • The requestID in the exception returned by the OSS SDK.
  • The packets captured by running the following tcpdump command when you upload the object again.
    tcpdump -i <Outbound port name> -s0 host <OSS endpoint> -w faild.pcap

The upload and download transmission speed of ossutil is far better than the OSS SDK for Python.

ossutil is developed in Go and provides better performance in concurrent upload scenarios. If the download speed of the OSS SDK for Python is far slower than that of ossutil, it may because that crcmod is not properly installed. For more information about crcmod, see Installation. If the problem persists, click here to submit a ticket.

The multipart upload function provided by the OSS SDK for Python can be called in CentOS systems. However, a 403 error is returned when the multipart upload function is called on Ubuntu systems.

  • Use tcpdump to capture packets on the client. Analyze the packets to determine whether the calculated signature is different from that on the OSS server because of incorrect header information in the request.
    POST /ttsservice%2Fpasswd? uploadId=D468E486D1D94D90A1AB8885A4E32AE0 HTTP/1.1
    Accept-Encoding: identity
    Accept: */*
    Content-Length: 137
    date: Sat, 29 Dec 2018 07:32:34 GMT
    authorization: OSS LTAIknFr:r2KPR0y4E0G5tnU/MYdcvXHPQQ4=
    Content-Type: application/x-www-form-urlencoded
    User-Agent: aliyun-sdk-python/2.6.0(Linux/4.4.0-31-generic/x86_64;3.4.3)
    <CompleteMultipartUpload><Part><PartNumber>1</PartNumber><ETag>"3195544E19D99658706D51EF5"</ETag></Part></CompleteMultipartUpload>HTTP/1.1 403 Forbidden
    Server: AliyunOSS
    Date: Sat, 29 Dec 2018 07:33:43 GMT
    Content-Type: application/xml
    Content-Length: 1122
    Connection: keep-alive
    x-oss-request-id: 5C2723573183A12D
    x-oss-server-time: 0
    <? xml version="1.0" encoding="UTF-8"? >
     <Message>The request signature we calculated does not match the signature you provided. Check your key and signing method. </Message>
     <RequestId> 5C2723573183A12D </RequestId>
     <OSSAccessKeyId> LTAXXX </OSSAccessKeyId>
    Sat, 29 Dec 2018 07:32:34 GMT
    /rokid/ttsservice/passwd? uploadId=D468E486D1D94D90A1AB8885A4E32AE0</StringToSign>
     <StringToSignBytes>50 4F 53 54 0A 0A 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 2D 77 77 77 2D 66 6F 72 6D 2D 75 72 6C 65 6E 63 6F 64 65 64 0A 53 61 74 2C 20 32 39 20 44 65 63 20 32 30 31 38 20 30 37 3A 33 32 3A 33 34 20 47 4D 54 0A 2F 72 6F 6B 69 64 2D 6F 70 73 2D 6D 6F 64 65 6C 2F 74 74 73 73 65 72 76 69 63 65 2F 70 61 73 73 77 64 3F 75 70 6C 6F 61 64 49 64 3D 44 34 36 38 45 34 38 36 44 31 44 39 34 44 39 30 41 31 41 42 38 38 38 35 41 34 45 33 32 41 45 30 </StringToSignBytes>
    The preceding code is the packets captured by tcpdump on the client. Use the captured header information in the following script to caculate the signature, and check whether the calculated signature is consistent with the signature in the captured packets.
    import base64
    import hmac
    import sha
    mac ="<Secretkey>","POST\n\napplication/x-www-form-urlencoded\nSat, 29 Dec 2018 07:32:34 GMT\n/rokid/ttsservice/passwd? uploadId=D468E486D1D94D90A1AB8885A4E32AE0", sha)
    Signature = base64.b64encode(mac.digest())
    • If the signatures are consistent, the signature in the request generated by the SDK is correct. If the calculated signature is inconsistent with the signature in the captured packets, it may because that the MD5 hash calculated based on the signature is different in Ubuntu systems due to compatibility issues.
    • If the signature received by the server and that calculated on the client are inconsistent, the content in the request has been modified. We recommend that you upload the object through HTTPS.

When you use the OSS SDK for Python in MacOS systems to start multiple threads and perform operations on OSS resources in a subthread, an error occurs if you import tensorflow. No error occurs if you do not import tensorflow. In addition, if you do not start multiple threads, tensorflow can be imported without errors.

When you use the OSS SDK for Python to start multiple threads, the following error occurs:
objc[2483]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called.
objc[2483]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.


Add an environment variable OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES, as shown in the following figure:

For more information, visit Workarounds for compatibility.

Other errors

For more information about the errors that occur during the installation of the OSS SDK for Python, see Installation.