1Panel-dev/1Panel · error · ValueError

unexpected-container-path

Error message

unexpected-container-path

What it means

Raised while parsing managed nginx configs (1panel-module-*.conf) when a load_module directive's argument does not start with the expected container prefix path. The diagnostic maps container paths to host paths under the modules root, so an unexpected prefix means it cannot even attempt the mapping.

Source

Thrown at scripts/openresty-modules/diagnose-install.sh:271

import re
import sys

config_root = pathlib.Path(sys.argv[1])
modules_root = pathlib.Path(sys.argv[2]).resolve()
container_prefix = "/usr/local/openresty/nginx/modules/1panel/"
pattern = re.compile(r"^\s*load_module\s+([^;]+);", re.MULTILINE)
failed = False
print("config\tcontainer_path\thost_path\tresult")
if config_root.exists():
    for config in sorted(config_root.glob("1panel-module-*.conf")):
        content = config.read_text(encoding="utf-8")
        for value in pattern.findall(content):
            container_path = value.strip().strip('"\'')
            result = "OK"
            host_path = ""
            try:
                if not container_path.startswith(container_prefix):
                    raise ValueError("unexpected-container-path")
                relative = pathlib.PurePosixPath(container_path[len(container_prefix):])
                if ".." in relative.parts:
                    raise ValueError("unsafe-path")
                resolved = (modules_root / pathlib.Path(*relative.parts)).resolve(strict=True)
                if modules_root not in resolved.parents or not resolved.is_file():
                    raise ValueError("missing-artifact")
                host_path = str(resolved)
            except Exception as error:
                result = str(error)
                failed = True
            print("\t".join([config.name, container_path, host_path, result]))
sys.exit(1 if failed else 0)
PY
    then
        mark_passed "managed load_module configs"
    else
        mark_failed "managed load_module configs"
    fi

View on GitHub (pinned to 5ac7c80881)

Solutions

  1. Edit the 1panel-module-*.conf so load_module uses the expected container path prefix (the one 1Panel mounts the modules volume at)
  2. Reinstall the module through 1Panel so the managed config is regenerated correctly
  3. Move hand-customized module loads out of the managed 1panel-module-*.conf files into your own include

Example fix

# before
load_module /usr/local/openresty/nginx/modules/1panel-foo.so;
# after
load_module /usr/local/bin/1panel/modules/1panel-foo.so;  # use the configured container_prefix
Defensive patterns

Strategy: validation

Validate before calling

grep -rn 'load_module' /opt/1panel/apps/openresty/openresty/conf/conf.d/1panel-module-*.conf | grep -v '<container_prefix>'  # must be empty

Prevention

When it happens

Trigger: A 1panel-module-*.conf contains load_module /usr/local/openresty/nginx/modules/x.so (or any path not beginning with container_prefix); running diagnose-install.sh's config check finds it via the regex ^\s*load_module\s+([^;]+);.

Common situations: Someone hand-edited a managed config and used the openresty default module dir; a module install template rendered the wrong base path; configs written for a different container image layout.

Related errors


AI-assisted analysis of 1Panel-dev/1Panel@5ac7c80881 (2026-08-15). Data as JSON: /api/errors/994ae33a1a2b325b. Report an issue: GitHub.