Repository navigation
[BUG] Filesystem server crashes completely when any configured path is invalid #2113
Description
[BUG] Filesystem server crashes completely when any configured path is invalid
Description
The MCP filesystem server shuts down entirely if ANY path in the configuration becomes invalid (unmounted volume, disconnected network share, typo). This makes the protocol fragile and unsuitable for production use.
Current Behavior
When any path is inaccessible:
- Entire filesystem server shuts down
- ALL file access is lost (not just the invalid path)
- No error recovery possible through Claude
- Must restart Claude Desktop to restore functionality
Expected Behavior
- Invalid paths should be skipped with a warning
- Valid paths should continue working
- Server should log errors but not crash
- Graceful degradation, not total failure
Steps to Reproduce
- Configure MCP filesystem with a network mount:
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/username/Desktop",
"/Volumes/NetworkDrive" // This is a Samba mount
]
}- Start Claude Desktop - filesystem works normally
- Disconnect network/unmount the Samba share
- Filesystem server crashes completely
- Cannot access even
/Users/username/Desktopanymore
Impact
- Severity: Critical
- Frequency: Happens whenever network conditions change
- Workaround: None - must restart Claude Desktop
Real-World Example
Working on a project with files on both local disk and a Samba mount. Network hiccup occurs:
- Samba mount at
/Volumes/Codebecomes unavailable - MCP filesystem server completely dies
- Cannot read local logs to debug
- Cannot edit local config files to remove the bad path
- Cannot continue any file-based work until full restart
Proposed Solution
// pseudocode
async function initializePaths(configuredPaths) {
const validPaths = [];
for (const path of configuredPaths) {
try {
await fs.access(path);
validPaths.push(path);
console.log(`✓ Registered path: ${path}`);
} catch (error) {
console.warn(`✗ Skipping inaccessible path: ${path} - ${error.message}`);
// Continue with other paths instead of crashing
}
}
if (validPaths.length === 0) {
throw new Error("No valid paths found");
}
return validPaths;
}Additional Context
This "all-or-nothing" approach contradicts basic fault tolerance principles. For MCP to be a production-ready standard for LLM tool integration, it must handle common scenarios like:
- Network drives going offline
- Typos in configuration
- Permissions changes
- Mounted volumes being unmounted
The current behavior makes MCP fragile and frustrating to use in real development environments.
Environment
- OS: macOS [your version]
- Claude Desktop: [your version]
- MCP filesystem server version: [check package.json]
Related Issues
- [Check if there are similar issues and reference them]
Note: This issue affects anyone using MCP with network storage, external drives, or complex file system configurations. The fix would significantly improve MCP's reliability and production readiness.
Activity
sebastien-rosset commentedon Aug 22, 2025
Related to #2483
cliffhall commentedon Oct 19, 2026
Closing: superseded by the v2 release.
Thank you for reporting this, and apologies for the long wait for a response.
Since this was filed, the reference servers have been rebuilt for the 2026-07-28 MCP specification (#4857) and released as v2 (2.0.0 on npm for the TypeScript servers, 2026.10.19 on PyPI for the Python servers). Each server now runs on v2 of its SDK, and the behavior described here has either been fixed or no longer exists in the same form. The server now skips an inaccessible configured directory at startup with a warning, exits only when none is accessible, and per-call validation touches only the directory containing the requested path, so one missing or unmounted directory no longer takes the others down.
This is not a judgment on whether the problem was real; it's a consequence of the code it describes having been replaced. This is happening as part of the backlog triage in #4875.
If this still happens on the v2 release, we'd genuinely like to know. Please open a fresh issue with the version you're running and steps to reproduce, and we'll look at it. Note that this repository accepts contributions as issues rather than pull requests; see
CONTRIBUTING.md.Thanks for taking the time to report it.