[FEAT] Obsidian CLI Support

[daichi-629]

Is this a new feature request?

• I have searched the existing issues

Wanted change

• I want to use Obsidian CLI to connect to the running instance inside the container (e.g., docker exec <container name> obsidian help)

Reason for change

Environment

Started with this compose.yml:

services:
  obsidian:
    image: lscr.io/linuxserver/obsidian:latest
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Tokyo
      - LC_ALL=ja_JP.UTF-8
    volumes:
      - ./config:/config
    ports:
      - 127.0.0.1:3030:3000
      - 127.0.0.1:3032:3031
    shm_size: "2gb"
    restart: unless-stopped

What I tried

1. Run CLI via docker exec -> it crashed with SUID sandbox error:

[1492:0302/224047.796385:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /opt/obsidian/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)

2. Attempted fixes:

• entrypoint in compose.yml to run chown/chmod -> no effect (permissions reverted during init)
• Mounting /etc/cont-init.d script -> no effect (permissions reverted during init)

3. Added an s6-overlay oneshot that runs after init-obsidian-config and restores permissions:

Mounted paths:

./s6-overlay/s6-rc.d/fix-chrome-sandbox:/etc/s6-overlay/s6-rc.d/fix-chrome-sandbox:ro
./s6-overlay/s6-rc.d/user/contents.d/fix-chrome-sandbox:/etc/s6-overlay/s6-rc.d/user/contents.d/fix-chrome-sandbox:ro

Files and contents:

s6-overlay/s6-rc.d/fix-chrome-sandbox/type
oneshot

s6-overlay/s6-rc.d/fix-chrome-sandbox/up
/etc/s6-overlay/s6-rc.d/fix-chrome-sandbox/run

s6-overlay/s6-rc.d/fix-chrome-sandbox/dependencies.d/init-obsidian-config

s6-overlay/s6-rc.d/user/contents.d/fix-chrome-sandbox

s6-overlay/s6-rc.d/fix-chrome-sandbox/run
#!/usr/bin/with-contenv bash
set -euo pipefail

# Ensure Electron SUID sandbox has correct ownership/permissions.
if [ -e /opt/obsidian/chrome-sandbox ]; then
  chown root:root /opt/obsidian/chrome-sandbox
  chmod 4755 /opt/obsidian/chrome-sandbox
fi

This removed the first error, but I then got another crash:

Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
[4749:0303/191307.985248:FATAL:content/browser/zygote_host/zygote_host_impl_linux.cc:207] Check failed: . : Invalid argument (22)
Trace/breakpoint trap (core dumped)

4. Adding the following to compose.yml fixed it:

    security_opt:
      - seccomp=unconfined

Proposed code change

• The current behavior resets /opt/obsidian ownership to abc:abc during init, which also resets chrome-sandbox and breaks the CLI.
• Please change the image so that chrome-sandbox remains root:root 4755 after startup.
  • Option A: exclude chrome-sandbox from the recursive lsiown -R abc:abc /opt/obsidian.
  • Option B: add a built-in s6 oneshot (after init-obsidian-config) that restores root:root 4755 on /opt/obsidian/chrome-sandbox.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[prrtzt]

Running into the same issue. Would be great to be able to use the CLI that way.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[NWalker4483]

I'd like to see the same

[daichi-629]

Update: I found a better workaround on my side, so my earlier conclusion about needing security_opt: seccomp=unconfined was incorrect for my case.

The current issue for me is not just the sandbox. There is also a newer runtime-path/socket mismatch when invoking the real binary directly via docker exec.

In short:

• Directly calling /opt/obsidian/obsidian (or a symlink to it such as /config/.local/bin/obsidian) is not equivalent to calling a wrapper with the expected runtime environment.
• In my container, the running app creates the CLI socket at /config/.XDG/.obsidian-cli.sock.
• But direct invocation looked for /config/.obsidian-cli.sock, which caused Unable to connect to main process.

This appears to be a newer behavior change on my side, because the original report was focused on the sandbox failure; the socket-path issue only became clear later during tracing.

What fixed it for me was:

• set XDG_RUNTIME_DIR=/config/.XDG
• invoke Obsidian through a wrapper that runs /opt/obsidian/obsidian --no-sandbox "$@"

I ended up adding a small wrapper in /usr/local/bin/obsidian:

#!/bin/sh
export XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-/config/.XDG}"
exec /opt/obsidian/obsidian --no-sandbox "$@"

With that in place, I can run:

docker exec -u abc <container> obsidian help

and it connects to the running instance correctly, without seccomp=unconfined.

So at this point I no longer think seccomp=unconfined is required for this use case. My earlier report mixed two things together:

• the original sandbox problem from direct binary execution
• a later socket-path/runtime-environment problem that seems to show up with the current app behavior

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.