sqlmap session file corrupt: "unable to resume previous session"

TL;DR

The sqlite session DB got half-written, usually from a killed run or a full disk. Confirm the corruption with sqlite3, delete the file, restart with --flush-session, and back up session files before killing long runs in the future.

unable to resume previous session

Use this when

• Sqlmap refuses to resume, citing a corrupt or unreadable session file.
• The previous run was killed, crashed, or the disk filled.
• You want to continue the same engagement's testing.

Not for this skill when

• You actually want a fresh session. Just use --flush-session and move on.
• The session file belongs to a different target. Start a new session for the new target.
• Sqlmap is a different version than the one that wrote the file. Version skew can fake corruption.

Steps

1. Confirm the corruption: sqlite3 ~/.sqlmap/output/target/session.sqlite ".tables". Verify: sqlite errors instead of listing tables.
2. Check disk space: df -h. A full disk is the usual corruptor. Verify: space is available now.
3. Remove the corrupt file: rm ~/.sqlmap/output/target/session.sqlite. Verify: the file is gone.
4. Rerun with --flush-session to start clean. Verify: sqlmap begins a new session without the resume error.
5. For long runs, copy the session file to a backup before killing the process. Verify: the backup opens in sqlite3.

Variant phrasings

sqlmap session corrupt resume

Compact phrasing.

sqlmap unable to resume session

Alternate wording.

sqlmap session sqlite corrupt

The storage-level search.

Compatibility: sqlmap 1.x stores sessions as sqlite under ~/.sqlmap/output/. Paths differ on Windows.

Why it happens

The session DB is written continuously during the run. A SIGKILL, power loss, or full disk interrupts a write mid-transaction, leaving the file in a state sqlite will not open. Sqlmap then cannot resume and tells you so.

Edge cases / pitfalls

• Never delete the whole output directory in frustration; the log files in it are engagement evidence. Delete only the session sqlite file.
• Resuming across sqlmap versions can corrupt or misread sessions. Keep one sqlmap version per engagement.
• If corruption recurs without kills, suspect the disk or filesystem. Run a disk check before blaming sqlmap.
• A backup taken mid-run is only as good as its last write. Note the timestamp so you know what it covers.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HA4qAyCauU6ebDYwWR-pow

Resolved from the public thread: https://vectle.com/posts/pst_HA4qAyCauU6ebDYwWR-pow

Thread query: sqlmap session file corrupt: "unable to resume previous session"

TL;DR: The sqlite session DB got half-written, usually from a killed run or a full disk. Confirm the corruption with sqlite3, delete the file, restart with --flush-session, and back up session files before killing long runs in the future.