ha-mcp-dev 7.14.2.dev2173__tar.gz → 7.14.2.dev2175__tar.gz

{ha_mcp_dev-7.14.2.dev2173/src/ha_mcp_dev.egg-info → ha_mcp_dev-7.14.2.dev2175}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ha-mcp-dev
-Version: 7.14.2.dev2173
+Version: 7.14.2.dev2175
 Summary: Home Assistant MCP Server - Complete control of Home Assistant through MCP
 Author-email: Julien <github@qc-h.net>
 License: MIT

{ha_mcp_dev-7.14.2.dev2173 → ha_mcp_dev-7.14.2.dev2175}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "ha-mcp-dev"
-version = "7.14.2.dev2173"
+version = "7.14.2.dev2175"
 description = "Home Assistant MCP Server - Complete control of Home Assistant through MCP"
 readme = "README.md"
 # Upper bound widened to <3.15 so the package installs on Home Assistant's

{ha_mcp_dev-7.14.2.dev2173 → ha_mcp_dev-7.14.2.dev2175}/src/ha_mcp/__main__.py

@@ -155,13 +155,17 @@ This typically happens when running Docker without the -i flag:
 To fix this, use one of the following options:
 
   1. Add the -i flag to enable interactive stdin:
-     docker run -i -e HOMEASSISTANT_URL=... -e HOMEASSISTANT_TOKEN=... \\
+     docker run -i -v ha-mcp-data:/home/mcpuser/.ha-mcp \\
+       -e HOMEASSISTANT_URL=... -e HOMEASSISTANT_TOKEN=... \\
        ghcr.io/homeassistant-ai/ha-mcp:latest
 
   2. Use HTTP mode instead (recommended for servers/automation):
-     docker run -d -p 8086:8086 -e HOMEASSISTANT_URL=... -e HOMEASSISTANT_TOKEN=... \\
+     docker run -d -p 8086:8086 -v ha-mcp-data:/home/mcpuser/.ha-mcp \\
+       -e HOMEASSISTANT_URL=... -e HOMEASSISTANT_TOKEN=... \\
        ghcr.io/homeassistant-ai/ha-mcp:latest ha-mcp-web
 
+The -v flag keeps your settings when the container is re-created.
+
 For more information, see:
   https://github.com/homeassistant-ai/ha-mcp#-docker
 

{ha_mcp_dev-7.14.2.dev2173 → ha_mcp_dev-7.14.2.dev2175}/src/ha_mcp/auth/provider.py

@@ -222,7 +222,7 @@ class HomeAssistantOAuthProvider(OAuthProvider):
                 "Failed to persist OAuth client registry to %s (%s: %s). "
                 "Clients will need to re-register after the next restart. "
                 "Mount a persistent volume to fix this: "
-                "docker run -v ha_mcp_data:/home/mcpuser/.ha-mcp ...",
+                "docker run -v ha-mcp-data:/home/mcpuser/.ha-mcp ...",
                 path,
                 type(exc).__name__,
                 exc,

{ha_mcp_dev-7.14.2.dev2173 → ha_mcp_dev-7.14.2.dev2175}/src/ha_mcp/utils/data_paths.py

@@ -7,6 +7,7 @@ JSONL).
 
 from __future__ import annotations
 
+import contextlib
 import functools
 import logging
 import os
@@ -34,11 +35,15 @@ def get_data_dir() -> Path:
        location", and silently writing to ``$HOME`` instead would surprise
        users who chose the override deliberately.
     4. ``<tempdir>/ha-mcp`` — last-resort fallback when the previously
-       chosen step fails (read-only filesystem; ``HOME`` unset so
-       ``Path.home()`` resolves to ``/``; or ``HA_MCP_CONFIG_DIR`` set but
-       its mkdir raises). Loses persistence across restarts but lets the
-       server start; users wanting persistence should set
-       ``HA_MCP_CONFIG_DIR`` to a writable path.
+       chosen step cannot be created *or written to* (read-only filesystem;
+       ``HOME`` unset so ``Path.home()`` resolves to ``/``; a Docker volume
+       whose mount point ended up owned by another user; or
+       ``HA_MCP_CONFIG_DIR`` set but unusable). Loses persistence across
+       restarts but lets the server start; users wanting persistence should
+       set ``HA_MCP_CONFIG_DIR`` to a writable path.
+
+    Each candidate is probed with a real write, not just a ``mkdir`` — see
+    :func:`_try_write` for why existence alone is not enough.
 
     Memoized so the fallback warning typically emits once at startup
     rather than on every save/load HTTP request. ``lru_cache`` serializes
@@ -53,11 +58,57 @@ def get_data_dir() -> Path:
 
 
 def _try_mkdir(path: Path) -> OSError | None:
-    """Create ``path`` (idempotent); return the ``OSError`` on failure, else ``None``."""
+    """Create ``path`` and confirm it is writable.
+
+    Returns the ``OSError`` on failure, else ``None``.
+    """
     try:
         path.mkdir(parents=True, exist_ok=True)
     except OSError as e:
         return e
+    return _try_write(path)
+
+
+def _try_write(path: Path) -> OSError | None:
+    """Confirm ``path`` actually accepts writes; return the ``OSError``, else ``None``.
+
+    ``Path.mkdir(exist_ok=True)`` reports success for a directory that already
+    exists no matter who owns it or whether the filesystem is read-only — it
+    only re-stats the path. So "mkdir worked" does not mean "we can write
+    here", and Docker deployments live entirely inside that gap: the mount
+    point always exists by the time Python runs, because the image ships it
+    and Docker creates it when mounting a volume. Without this probe a
+    root-owned volume, a ``read_only: true`` filesystem or a ``--user``
+    override would each resolve as a perfectly good data dir and the fallback
+    warning below would never fire — persistence would just vanish with no
+    startup signal, which is the failure issue #2078 reported.
+
+    Probes by creating a real file rather than calling ``os.access``.
+    ``access(2)`` answers for the real UID rather than the effective one, and
+    it reports success for a process holding ``CAP_DAC_OVERRIDE`` (root in a
+    default container) whose writes a later ``--user`` drop would reject. It
+    does catch a read-only mount — Linux returns ``EROFS`` for ``W_OK`` — so
+    that is not the reason to avoid it. ``mkstemp`` is chosen because it
+    exercises the same syscalls the actual writes use (see
+    ``settings_ui._persistence``), which no permission query can stand in for.
+    """
+    try:
+        fd, name = tempfile.mkstemp(prefix=".ha-mcp-write-probe-", dir=path)
+    except OSError as e:
+        return e
+    try:
+        os.close(fd)
+        # Removing the probe is part of the check, not just cleanup: the real
+        # writers finish with ``os.replace`` onto the target name, so a share
+        # or ACL that grants create but denies unlink/replace (seen on some
+        # SMB/NFS exports) cannot actually persist anything. Letting either
+        # call raise out of here instead of returning it would abort startup
+        # rather than fall back.
+        os.unlink(name)
+    except OSError as e:
+        with contextlib.suppress(OSError):
+            os.unlink(name)
+        return e
     return None
 
 
@@ -82,7 +133,9 @@ def _prepare_fallback(preferred: Path | None) -> Path:
         )
     else:
         logger.warning(
-            "Cannot write ha-mcp data to %s (read-only filesystem or HOME unset). "
+            "Cannot write ha-mcp data to %s (read-only filesystem, HOME unset, "
+            "or the directory is owned by another user — a Docker volume "
+            "mounted there must be writable by the container's user). "
             "Falling back to %s — data will NOT persist across restarts. "
             "Set HA_MCP_CONFIG_DIR to a writable path for persistence.",
             preferred,
@@ -104,8 +157,9 @@ def _resolve_data_dir() -> Path:
         if err is None:
             return custom_dir
         logger.warning(
-            "HA_MCP_CONFIG_DIR=%s could not be prepared (%s: %s); "
-            "falling back to a tmpdir.",
+            "HA_MCP_CONFIG_DIR=%s is not usable — it must exist or be "
+            "creatable AND be writable by this process (%s: %s). It will NOT "
+            "be read from either; falling back to a tmpdir.",
             custom_dir,
             type(err).__name__,
             err,

{ha_mcp_dev-7.14.2.dev2173 → ha_mcp_dev-7.14.2.dev2175/src/ha_mcp_dev.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ha-mcp-dev
-Version: 7.14.2.dev2173
+Version: 7.14.2.dev2175
 Summary: Home Assistant MCP Server - Complete control of Home Assistant through MCP
 Author-email: Julien <github@qc-h.net>
 License: MIT