ClickHouse DB::Exception: Cannot seek through file

The "DB::Exception: Cannot seek through file" error in ClickHouse happens when the server is unable to reposition the read/write offset within an open file. This error, identified by the CANNOT_SEEK_THROUGH_FILE code, typically occurs during query execution when ClickHouse needs to jump to a specific position in a data file -- for instance, when reading a particular column or granule from a MergeTree part. A failed seek usually indicates a problem with the file itself or the filesystem beneath it.

Impact

A seek failure impacts ClickHouse operations in these ways:

Queries that need to access the affected file will fail
Mark and index files that cannot be seeked will prevent reading entire data parts
Background merges involving the corrupted part will be blocked
The table may become partially unreadable until the problematic part is repaired or replaced

Common Causes

Corrupted or truncated data files where the expected offsets no longer exist
Filesystem corruption causing incorrect file size reporting
Storage device failure leading to inconsistent file state
A file being modified or truncated by an external process while ClickHouse is reading it
Incompatible or buggy FUSE filesystem drivers that do not properly support lseek
Attempting to seek in a pipe or non-seekable file descriptor due to a software bug

Troubleshooting and Resolution Steps

Identify the affected file from the error log:
```
grep "Cannot seek" /var/log/clickhouse-server/clickhouse-server.err.log | tail -5
```
The log entry will include the file path and the offset that was requested.
Verify the file exists and check its size:
```
ls -la /var/lib/clickhouse/data/your_db/your_table/affected_part/
```
Compare the actual file size against what ClickHouse expects. If the file is smaller than the requested seek offset, it has been truncated.
Run a checksum verification:
```
CHECK TABLE your_db.your_table;
```
This will identify parts with checksum mismatches or structural problems.
Check filesystem integrity:
```
dmesg | grep -i "error\|corrupt\|i/o"
```
Filesystem-level corruption may require an offline fsck to repair.
Detach and re-fetch the broken part (replicated tables):
```
ALTER TABLE your_db.your_table DETACH PART 'broken_part_name';
```
On a replicated table, ClickHouse will automatically download a fresh copy from another replica.
For non-replicated tables, restore from backup: If no replica exists, restore the part from your most recent backup. You can copy part directories directly into the detached folder and then attach them:
```
ALTER TABLE your_db.your_table ATTACH PART 'restored_part_name';
```
Investigate storage health:
```
smartctl -a /dev/sda
```
Replace or repair failing hardware before the issue spreads to other parts.

Best Practices

Enable checksums (on by default in MergeTree) so corruption is detected early
Use replicated tables in production to allow automatic recovery from corrupted parts
Monitor disk health and set up alerts for SMART warnings or I/O errors
Avoid running tools that modify files in the ClickHouse data directory
Schedule regular backups to ensure you can recover non-replicated data
Test filesystem behavior before using non-standard or FUSE-based filesystems in production

Frequently Asked Questions

Q: What does "seek" mean in this context?
A: Seeking is the operation of moving to a specific byte offset within a file. ClickHouse uses seeks to efficiently read specific portions of data files (such as individual granules or column data) without scanning the entire file.

Q: Will CHECK TABLE fix the corruption?
A: No, CHECK TABLE only detects problems. To fix them, you need to detach the broken part and either let replication recover it or restore it from a backup.

Q: Can this error occur on SSDs?
A: Yes. While SSDs are generally more reliable for random access, they can still experience firmware bugs, wear-related failures, or power-loss corruption that leads to seek errors.

Q: Is there a way to skip the broken part and still query the rest of the data?
A: You can detach the broken part, which removes it from the active dataset. Queries will then succeed using the remaining parts. The detached part can be investigated or restored separately.