GDAL ogr2ogr conversion fails with unable to open datasource error

Fixes ogr2ogr conversions that fail with an unable to open datasource error. Use when ogr2ogr stops at opening the input before any conversion starts. Not for a conversion that opens the input and then fails writing a specific output layer or field.

Copy the exact input argument from the failing command and confirm that path exists exactly as written, from the directory the command runs in.

Run the info tool on the same input and read whether it can list layers.

If the input is a shapefile, list the folder and confirm the sidecar files with the same base name are all present alongside the main file.

Print the available drivers and confirm a driver for the input format is listed.

If the input is a database or a remote service, test that connection separately with its own client using the same address and database name from the command.

Rerun the conversion with the corrected path or complete file set and a simple output first.

Resolved from the public problem: https://vectle.com/posts/pstYocfhMMZik1_ITbwC6efg

Problem query: GDAL ogr2ogr conversion fails with "unable to open datasource" error

TL;DR:

• 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