Telegram channel setup fails: EACCES on /sandbox/.openclaw/telegram due to root-owned overlayfs layers

[Amuratii]

Description

After configuring a Telegram bot token via policy-add and restarting the
gateway, the gateway repeatedly logs:

failed to persist update offset: Error: EACCES: permission denied, mkdir '/sandbox/.openclaw/telegram'

The /sandbox/.openclaw directory is owned by root inside the sandbox, so the
sandbox user (uid 998) cannot create subdirectories in it.

Expected behavior
The gateway creates /sandbox/.openclaw/telegram and persists update offsets
without error.

Actual behavior
The gateway fails with EACCES on mkdir. The directory cannot be created because
.openclaw is root-owned in the overlayfs lower layers (snapshots 82 and 83),
and the sandbox user has no write access despite being the nominal owner of
the sandbox home.

Workaround
Create the directory through the live rootfs mount on the host:

ROOTFS=$(sudo docker exec openshell-cluster-nemoclaw cat /proc/mounts
| grep -oP '/run/k3s[^ ]*rootfs' | head -1)
sudo docker exec openshell-cluster-nemoclaw mkdir -p
$ROOTFS/sandbox/.openclaw/telegram
sudo docker exec openshell-cluster-nemoclaw chown 998:998
$ROOTFS/sandbox/.openclaw/telegram

Suggested fix
The onboarding or installer should ensure /sandbox/.openclaw and any
channel-specific subdirectories are created with the correct ownership
(uid/gid 998) before the gateway starts, either in the blueprint or in the
nemoclaw onboard step.

Reproduction Steps

1. Run curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
2. Complete onboarding
3. Run nemoclaw <id> policy-add and select the telegram preset
4. Add a bot token to openclaw.json
5. Start the gateway with openclaw gateway
6. Send /start to the bot

Environment

Environment

• OS: Ubuntu 24 (XPS 15 9570)
• NemoClaw: v0.1.0
• OpenClaw: 2026.3.11
• Docker: running via systemd
• Node.js: v24.14.1

Debug Output

**Debug output**

Inside the sandbox, `stat` confirms the directory is owned by the sandbox user
but writes are still blocked:

  sandbox@qreeftv1:~$ stat /sandbox/.openclaw
    File: /sandbox/.openclaw
    Size: 4096          Blocks: 8          IO Block: 4096   directory
  Device: 0,341   Inode: 22292592    Links: 1
  Access: (0755/drwxr-xr-x)  Uid: (  998/ sandbox)   Gid: (  998/ sandbox)

  sandbox@qreeftv1:~$ mkdir /sandbox/.openclaw/telegram
  mkdir: cannot create directory '/sandbox/.openclaw/telegram': Permission denied

The unusual device number (0,341) indicates the overlayfs is not correctly
surfacing write access through to the upper layer despite correct ownership
metadata. The `telegram` directory, when created externally in the upper
snapshot, appears as `d?????????` inside the sandbox — unreadable and
inaccessible.

Inspecting the overlayfs layers on the host confirms `.openclaw` exists in 
multiple lower snapshots (82 and 83) both owned by root, with the upper 
writable layer (snapshot 85) unable to override them cleanly:

  $ sudo ls -la .../snapshots/82/fs/sandbox/.openclaw
  drwxr-xr-x 1 root root 4096 ...

  $ sudo ls -la .../snapshots/83/fs/sandbox/.openclaw
  drwxr-xr-x 2 root root 4096 ...

  $ sudo ls -la .../snapshots/85/fs/sandbox/.openclaw
  drwxr-xr-x 3 998 998 4096 ...   ← upper layer, correct ownership
                                      but not visible inside sandbox

Logs

**Gateway logs**

Filtered from /tmp/openclaw/openclaw-2026-03-26.log:

  15:00:43 {"subsystem":"telegram/network"}: autoSelectFamily=true (default-node22)
  15:00:43 {"subsystem":"telegram/network"}: dnsResultOrder=ipv4first (default-node22)
  15:00:45 {"subsystem":"gateway/channels/telegram"}: [default] starting provider
  15:00:45 {"subsystem":"telegram/network"}: autoSelectFamily=true (default-node22)
  15:00:45 {"subsystem":"telegram/network"}: dnsResultOrder=ipv4first (default-node22)
  15:05:30 {"subsystem":"gateway/channels/telegram"}: failed to persist update 
           offset: Error: EACCES: permission denied, mkdir '/sandbox/.openclaw/telegram'

The provider starts successfully and receives messages from Telegram (bot token
is valid, network policy is correctly applied) but crashes on the first attempt
to write state.

Checklist

• I confirmed this bug is reproducible
• I searched existing issues and this is not a duplicate

[WuKongAI-CMU]

Opened PR #981 for this. The patch precreates writable Telegram state under /sandbox/.openclaw-data/telegram, symlinks /sandbox/.openclaw/telegram into that writable state path before .openclaw is locked, and adds a regression test so the Dockerfile layout does not drift back.