schwab-mcp-custom/BUG.md

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.