We build software, dev stacks & apps — and we still offer hosting.
hTech

Troubleshooting: Start Here Print

  • 0

Start here

Every fault this module can raise carries a short, fixed, lower-case code such as manifest_signature_invalid or bucket_not_empty. That code — never the sentence around it — is what you should search for or quote when you contact support: sentences get reworded, codes do not. If you have a code in hand, go straight to Error codes: what each one means in this category, which lists all of them; it names which of the eight family articles below covers it.

If you do not have a code yet, or you are not sure which family a symptom belongs to, answer these in order.

1. Did something just fail while you were pressing a button, or did it fail on its own overnight?

  • You pressed Update and got a refusal → Update and manifest faults. Every one of these ends with a plain statement of what was and was not changed; read that sentence before doing anything else.
  • You pressed Create, Suspend, Unsuspend or Terminate (or WHMCS's own automation queued one of those) and it did not go through → Provisioning and lifecycle faults.
  • Nobody pressed anything and a service is stuck, or an admin alert appeared → start with Storage account state faults; if the alert is explicitly about a licence, go to Licensing and activation faults instead.

2. Is the complaint from your customer, or from your own admin area?

  • A customer says a bucket, an upload, a folder or an Object Lock setting failed in their client area → S3 gateway, bucket and object faults. Most of these are your customer's data doing something specific — a retained version, a name the gateway will not host, a checksum that did not match — and are not a fault in this module.
  • You are looking at a server entry, a product, or the module's own Settings/Update page and something there is refused → Configuration faults covers a server entry's fields (token, domain, hostname); Licensing and activation faults covers the Licence Key specifically.

3. Is this about talking to IDrive e2 itself, or about this module's own bookkeeping?

A fault named by Reseller vendor API faults is IDrive e2's own reseller control-plane answering — a credential, a rate limit, a precondition already met. A fault named by Storage account state faults is this module's own database row for a service: sealed secrets, which owner a call belongs to, the module's schema. The two are easy to conflate because both can follow from the same underlying event; the family article each code sits in tells you which side of the line you are on.

4. Does the code's own family article say "not actionable" or "report this"?

A small number of codes — all of Operator alert faults, four of S3 gateway, bucket and object faults' Object Lock entries, and a handful named explicitly inside Storage account state faults — are internal consistency guards. They exist to stop this module writing a record that looks real but is not, and none of them is something a customer's action or an operator's setting can trigger in ordinary use. If you are looking at one of these, there is nothing to configure: note the code and the approximate time and report it, because seeing one at all means something upstream of this module handed it a value it should never have received.

What no code in this category will ever tell you

No fault code here carries an invented number, an estimated wait time, or a promise about how fast anything will be fixed. Where a code's own text says "wait" or "try again", that is because the shipped code names that as the correct next step — not because this knowledgebase is guessing at one.


Was this answer helpful?

Related Articles

« Back