b3nw
ad4d7317f4
All checks were successful
Build and Push Docker Image / build (push) Successful in 34s
25 lines
3.1 KiB
Markdown
25 lines
3.1 KiB
Markdown
# RESOLVED: Gemini Deployment Incapacity (Docker Mount Persistence)
|
|
|
|
## Status: RESOLVED
|
|
The critical Docker filesystem mounting error on the remote host `docker-test` has been successfully diagnosed and resolved. The `schwab-mcp` container is now correctly mounting `cookies.json` and `config.json` as files, and the authentication cookies have been successfully injected.
|
|
|
|
## Root Cause Analysis
|
|
The persistent `[Errno 21] Is a directory: 'config.json'` error was caused by a compounding sequence of abstraction mismatches between Komodo and the Docker daemon:
|
|
|
|
1. **Komodo's Path Parsing (`/host/...`)**: When Komodo deploys a stack with `files_on_host: true`, it requires the `run_directory` to be prefixed with `/host/` (e.g., `/host/opt/schwab-mcp-custom`) because the Komodo Periphery agent runs inside a container where the host filesystem is mounted at `/host`.
|
|
2. **Docker Compose Path Resolution**: When the periphery agent executes `docker compose up -d`, it parses the relative paths in the `compose.yaml` (e.g., `./cookies.json:/app/cookies.json`) relative to its *current working directory*, translating them to `/host/opt/schwab-mcp-custom/cookies.json`.
|
|
3. **Docker Daemon Absolute Paths**: The periphery agent passes these translated paths to the Docker daemon running on the host machine. The host Docker daemon attempts to bind mount `/host/opt/schwab-mcp-custom/cookies.json`. Since this path doesn't exist on the actual host (the host path is `/opt/...`, without the `/host/` prefix), the Docker engine's default behavior is to automatically create **empty directories** at the missing source path.
|
|
4. **Docker Volume Persistence**: Once Docker creates these directories, subsequent `docker compose up -d` commands (even if the `compose.yaml` paths are corrected to absolute host paths) fail to overwrite the directory mounts with file mounts. The container remains locked into the initial, erroneous directory state.
|
|
|
|
## Resolution Steps Taken
|
|
To break the error loop and establish a clean state, the following manual interventions were required on the `docker-test` host:
|
|
|
|
1. **Hard Teardown**: Stopped and removed all containers and networks associated with the `schwab-mcp-custom` stack (`docker compose down`).
|
|
2. **Filesystem Purge**: Manually deleted the erroneous directories created by Docker (`rm -rf cookies.json config.json`).
|
|
3. **Explicit File Creation**: Explicitly created the required files on the host before Docker could intervene (`touch cookies.json config.json`).
|
|
4. **Clean Deployment**: Brought the stack back up manually (`docker compose up -d`), ensuring the bind mounts attached to the newly created files.
|
|
5. **Cookie Injection**: Once the file mounts were verified inside the container (`-rw-r--r--`), the valid session cookies were piped directly from the source repository into the host's `/opt/schwab-mcp-custom/cookies.json` file.
|
|
|
|
## Conclusion
|
|
The `schwab-mcp` service is now running in a structurally sound environment. The scraper has direct, file-level access to the injected session cookies, and the authentication errors stemming from the filesystem mismatch have been eliminated.
|