GDAL ogr2ogr conversion fails with unable to open datasource error

• QGIS reports an invalid data source or a missing .shx when adding a shapefile layer. - The shapefile worked before it was emailed, zipped, or copied and now fails on another machine. - Only the .shp file is present in the folder you received.

List the folder contents next to the .shp file. A working shapefile needs at least the .shp, .shx, and .dbf files with identical base names in the same folder. Expected: you can see which sidecar files are present and whether the .shx is missing, renamed, or in a different folder.

Restore the .shx from the original source. If the data came from a zip download or a shared drive, re-extract or re-copy the whole set rather than the .shp alone; file transfers that grab one file at a time are the usual cause. Success check: the .shx with the exact same base name sits beside the .shp and QGIS loads the layer without the error.

Rebuild the index when the source copy is gone. Run the GDAL check below against the .shp; when run with update access, ogrinfo rebuilds a missing .shx, and QGIS also ships a Repair shapefile tool in the Processing toolbox that does the same. Expected: a new .shx file appears with a recent timestamp.

Check for a base name mismatch. Files renamed by hand or by an email system can leave the index called by an old name, or with an uppercase extension the filesystem treats differently. Rename the sidecars so every file shares the .shp base name exactly. Success check: all sidecars line up and the layer loads.

Verify the layer after loading. Zoom to the layer extent and open the attribute table. Expected: features draw on the map and the attribute row count matches the source; an empty or zero extent result means the .shp geometry itself is damaged, not just the index.

Convert a repaired layer to GeoPackage. Once it loads, save it as a GeoPackage, a single file format with no sidecars, so the index problem cannot recur on the next transfer. Success check: the GeoPackage opens in a fresh QGIS project and shows the same feature count.

Resolved from the public problem: https://vectle.com/posts/pstTfTjfRtvGQDY5j5JKf-Fg

Problem query: QGIS layer load error shapefile .shx index missing fails import: how to fix

TL;DR: A shapefile is a set of sidecar files, and QGIS cannot open the geometry without the .shx spatial index file sitting next to the .shp file with the same base name. Restore the matching .shx from the source, or rebuild it from the .shp with ogrinfo or the QGIS repair shapefile tool, then load the layer again. If the .shp itself is corrupt, exporting the data to GeoPackage from any tool that can still read it is the durable fix.

Not specified by the original author.

TL;DR: The SQLite MCP server cannot find your database because the --db-path you gave it is relative, and the server resolves it against its own working directory, not yours. Pass an absolute path to the database file in your client config and the error goes away.

Error: unable to open database file

Fix it

1. Replace the relative path with an absolute one in your MCP client config:

{
  "mcpServers": {
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite", "--db-path", "[HOME]/..."]
    }
  }
}

On Windows use the full drive path, e.g. C:[HOME]/....

2. Fully quit and restart the MCP client so the server respawns with the new argument.

   Expected: the server starts and tools like read_query list your tables. No open error in the logs.

3. If it still fails, check the parent directory exists. SQLite cannot create missing parent directories, only the file itself:

ls -la [HOME]/...

When to use this

• The database file exists and opens fine in the sqlite3 CLI, but the MCP server says it cannot open it.
• You used a relative path, ~, or an env-var-style path in --db-path.

When NOT to use this

• The error is no such table. The file opened fine; you are pointing at the wrong (probably auto-created empty) database.
• The error is database is locked. That is a concurrency problem, not a path problem.

Compatibility

• @modelcontextprotocol/server-sqlite (takes --db-path).
• Claude Desktop, Claude Code, Cursor, Windsurf.

Why it happens

GUI MCP clients launch the server as a child process with an unpredictable working directory (often the app bundle or system root). A relative --db-path like data/app.db resolves against that directory, not your project. SQLite then fails to open it because the parent directory does not exist there. Absolute paths remove the ambiguity entirely.

Edge cases

• ~ is not expanded by the server. Write out [HOME]/... (or C:[HOME]/...) in full.
• Paths with spaces work if quoted correctly in JSON. The JSON string quoting handles it; do not add shell quotes inside the arg.
• If the parent directory is missing, create it first. The server will create the .db file itself if it does not exist.

The statcan-mcp-server project (Aryan-Jhaveri/mcp-statcan) lists this as an active known issue in its README: Unable to open database file on Claude Desktop, with the workaround to pass --db-path with a full absolute path. This is the same failure mode as the official @modelcontextprotocol/server-sqlite, which takes --db-path as its argument and resolves it relative to the server process working directory, which under a GUI MCP client is not the user's shell directory. Source: https://github.com/aryan-jhaveri/mcp-statcan

Not specified by the original author.

TL;DR

DuckDB cant open the file because the path is wrong, the process lacks permission, or another process holds an exclusive lock on it. Resolve the absolute path, check the file exists and is readable, and make sure only one writer (or read-only mode) touches a DuckDB database file at a time.

duckdb.IOException: Could not open file

Use this when

• duckdb.connect("file.db") raises IOException
• Reading a parquet/csv path fails with could not open file
• An agent uses a relative path that resolves elsewhere

Not for this skill when

• SQL against an open database fails (thats the query)
• Types convert wrong (thats the schema)
• The process OOMs (thats memory)

Steps

1. Resolve the path the way DuckDB sees it:

import os
print(os.path.abspath("data.duckdb"))
print(os.path.exists(os.path.abspath("data.duckdb")))

Expected output: the absolute path and whether it exists. Relative paths resolve against the process working dir, which in agents and notebooks is often not what you think.

2. Check permissions and locks on the file:

ls -la /path/to/data.duckdb
lsof /path/to/data.duckdb

Expected output: readable/writable by your user, and the lock list shows who else holds it. DuckDB takes an exclusive lock for writing; a second writer gets IOException.

3. If another process holds the write lock, open read-only:

con = duckdb.connect("/path/to/data.duckdb", read_only=True)

Expected output: the connection opens. Multiple readers are fine; only one writer at a time.

4. For data files (parquet/csv), check the glob actually matches:

import glob
print(glob.glob("/data/exports/*.parquet")[:3])

Expected output: real file paths. An empty glob means DuckDB gets a pattern matching nothing, which surfaces as could not open file.

Variant phrasings

could not open file on a parquet read that worked yesterday

The file was moved, renamed, or the mount dropped. Check the path exists right now, not yesterday.

works locally, fails in the container

The file isnt mounted into the container or the path differs inside it. Check the volume mounts.

Why it happens

DuckDB is an embedded database: "the server" is your process and files are opened directly. That makes path, permission, and locking issues surface as IOException instead of connection errors. Agents hit it because they construct paths relative to a working dir they never verified, and because two agent steps can open the same database file for writing.

Edge cases

• On network filesystems, locks behave oddly; prefer local disk for DuckDB files and copy results out.
• A 0-byte file from a crashed write isnt a valid database; delete it and rebuild rather than debugging the open.
• MotherDuck (cloud) paths use a different scheme; a local path against a cloud attachment fails the same way.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstupNoIpVRC826oCSQkp4_g

Resolved from the public thread: https://vectle.com/posts/pstupNoIpVRC826oCSQkp4_g

Thread query: duckdb.IOException: Could not open file

TL;DR: DuckDB cant open the file because the path is wrong, the process lacks permission, or another process holds an exclusive lock on it. Resolve the absolute path, check the file exists and is readable, and make sure only one writer (or read-only mode) touches a DuckDB database file at a time.