AlistGo/alist · error · TooManyDevices
too many active devices
Error message
too many active devices
What it means
errs.TooManyDevices signals that the remote account has more active sessions/devices than the provider permits, and a new one was refused or an existing one was invalidated. It is a package-level sentinel in internal/errs/device.go paired with SessionInactive for session-state problems.
Source
Thrown at internal/errs/device.go:6
package errs
import "errors"
var (
TooManyDevices = errors.New("too many active devices")
SessionInactive = errors.New("session inactive")
)
View on GitHub (pinned to 843d9dc814)
Solutions
- Log out unused devices/sessions from the provider's account security page, then retry
- Consolidate mounts: use one shared storage instance instead of mounting per-environment
- Check the provider's documented device limit and count active sessions against it
- If the limit is per-plan, upgrade the plan or use service/daemon accounts for automation
Example fix
// before
for _, cfg := range envConfigs {
go mount(cfg) // each mount = new device, exceeds cap
}
// after: single shared mount
mount(primaryCfg)
// other environments proxy through it Defensive patterns
Strategy: fallback
Validate before calling
if activeDevices >= providerDeviceLimit { return errs.TooManyDevices } Type guard
func isTooManyDevices(err error) bool { return errors.Is(err, errs.TooManyDevices) } Try / catch
err := mountStorage(cfg)
if errors.Is(err, errs.TooManyDevices) {
// fall back to reusing an existing shared mount instead of a new device
return reuseExistingMount(cfg)
} Prevention
- Track active sessions per account; log out unused devices during onboarding
- Prefer one shared storage mount over many per-service mounts
- Surface 'device limit reached' clearly so users know to prune sessions
When it happens
Trigger: Drivers or services that enforce device/session caps (e.g. cloud-drive clients that map one mounted storage to one 'device') returning this error when mounting additional instances beyond the account limit, or when the provider API reports a device-count violation during login/refresh.
Common situations: The same cloud account mounted in several environments (dev + prod + laptop) exceeding the provider's device quota; stale devices never logged out accumulating over time; team members sharing one account for testing; provider lowered the device limit.
Related errors
- missing cookie or qrcode account
- not get file info
- chunkNum invalid
- 123 offline download cannot target the root directory, pick
- r.Msg
AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15).
Data as JSON: /api/errors/01db27f4570582ee.
Report an issue: GitHub.