Skip to main content
tiCrypt 2.18.1

Troubleshooting

Common issues administrators may run into, and how to resolve them.

User stuck in pending state​

  • Confirm the user finished self-registration: a registered account appears in the Users table as New, not activated, and stays inactive until an administrator activates it. Registration has no email verification step. See Onboarding.
  • Check the escrow status for the user's key; a pending escrow approval will block activation.
  • Confirm an administrator has approved the account if your institution requires manual approval.
  • If the user remains stuck after these checks, review the audit log for activation errors.

Slurm job won't start​

  • Check that worker VMs are available and not all in use. See Worker VMs.
  • Confirm the target compute node is enabled and not in a "Do Not Schedule" or disabled state.
  • Verify the job's resource request does not exceed what any available worker VM can provide.
  • If the job still won't start, check the Slurm controller logs for scheduling errors.

Storage pool full​

  • Review libvirt volumes to identify which images or drives are consuming the most space.
  • Clean up old or unused VM images and orphaned volumes.
  • Confirm no stale snapshots are retained from past VM sessions.
  • If space remains constrained, expand the underlying storage pool or add an additional pool.

MFA login fails for every user​

  • Factor URL with a query string: The frontend appends ?port=<port> to the factor url as plain text, so a url that already contains ? breaks the hand-off. Remove the query string from the factor url in ticrypt-auth.conf. See MFA configuration.
  • Timestamp format: Users see "Bad multi-factor certificate" when the signature check fails. The factor page's payload must end with the timestamp field in ISO-8601 format with a +HH:MM offset; a millisecond timestamp, a Z suffix, or another field after timestamp breaks the signature. See MFA Payload Schema.
  • Expired certificate: Users also see "Bad multi-factor certificate" when the certificate's timestamp is older than the factor's cert-ttl. Check that the MFA server's clock is correct.
  • Repeated failures: After three rounds without enough valid MFA tokens, users see "failed to obtain enough MFA tokens after 3 tries". Fix the cause above, then have the user log in again.

MFA login fails for some users​

  • Case mismatch: By default the email in the MFA certificate must match the tiCrypt login ID exactly, including case. Set disable-case-sensitivity = true in the MFA configuration to lowercase the certificate's email before the lookup; this works when login IDs are lowercase.
  • Different account: Users see "Bad MFA certificate" when the certificate is for a different login ID than the one they are logging in with, for example when the SSO session belongs to someone else on a shared computer. Have the user sign out of the SSO provider and try again.