AlistGo/alist · warning

failed to generate unique share id

Error message

failed to generate unique share id

What it means

generateShareID draws 8-character random strings and checks uniqueness against the database up to 10 times. If all 10 candidates already exist (each random.String(8) collides with an existing share ID), it gives up with this error. With a 62-char alphabet this is statistically near-impossible unless the share table is enormous or randomness is degraded.

Source

Thrown at server/handles/share.go:202

func normalizeOptionalShareName(name, fallback string) string {
	if strings.TrimSpace(name) != "" {
		return strings.TrimSpace(name)
	}
	return fallback
}

func generateShareID() (string, error) {
	for range 10 {
		shareID := random.String(8)
		exists, err := db.ShareIDExists(shareID)
		if err != nil {
			return "", err
		}
		if !exists {
			return shareID, nil
		}
	}
	return "", fmt.Errorf("failed to generate unique share id")
}

func sharePasswordHash(password, salt string) string {
	return model.HashPwd(model.StaticHash(password), salt)
}

func validateCustomShareID(shareID string) error {
	if shareID == "" {
		return nil
	}
	if !shareIDPattern.MatchString(shareID) {
		return errShareIDInvalid
	}
	return nil
}

func resolveRequestedShareID(rawShareID, fallback string, excludeID uint) (string, error) {
	shareID := strings.TrimSpace(rawShareID)

View on GitHub (pinned to 843d9dc814)

Solutions

  1. Simply retry the share creation — a fresh random draw will almost certainly succeed
  2. Supply a custom share ID (validated by shareIDPattern) to bypass generation
  3. If it recurs, audit the random.String implementation/randomness source in your build
  4. Prune expired/deleted shares to shrink the occupied ID space
Defensive patterns

Strategy: retry

Try / catch

id, err := generateShareID()
if err != nil && strings.Contains(err.Error(), "failed to generate unique share id") {
    // retry once; if it persists, supply a custom pattern-valid share ID
}

Prevention

When it happens

Trigger: Creating/updating a share without a custom ID when the x_shares table already contains a huge number of IDs covering the 8-char space, or the random source is weak/predictable so candidates repeat existing values.

Common situations: Bulk-imported or scripted share creation filling the ID space; a fork/build with a broken random string generator; astronomically unlucky collision runs.

Related errors


AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15). Data as JSON: /api/errors/c8760344f9fbdbec. Report an issue: GitHub.