Summary
When running with SKIP_STORAGE=true (or when the Azure Files volume mount is removed due to Azure Policy blocking shared-key access), the entrypoint correctly falls back to an ephemeral /var/openclaw-state directory. However, writes to ~/.openclaw/workspace/BOOTSTRAP.md fail with a Write failed error in the Control UI, even though other workspace files (IDENTITY.md, USER.md) write successfully.
Error seen in Control UI
⚠️ ✍️ Write: `to ~/.openclaw/workspace/BOOTSTRAP.md` failed
Steps to reproduce
- Deploy with
SKIP_STORAGE=true (or remove the Azure Files volume mount from the container app)
- Open the WebChat UI and start a session
- Agent bootstraps and writes IDENTITY.md, USER.md successfully
- BOOTSTRAP.md write fails — the file appears as 0 B or is missing in the workspace panel
Root cause
The entrypoint.sh creates the symlink /mnt/state -> /var/openclaw-state when the volume isn't mounted, but only creates the top-level directory. It does not pre-create the workspace/, sessions/, or credentials/ subdirectories inside the ephemeral path.
OpenClaw's write tool appears to use an atomic write pattern (write to temp file, then rename into target directory). When workspace/ doesn't exist under /mnt/state, the rename target's parent doesn't exist and the write fails. Other files like IDENTITY.md succeed because they are written directly to ~/.openclaw/workspace/ (not via the /mnt/state persistence path), while BOOTSTRAP.md goes through the state-sync path.
Expected behaviour
entrypoint.sh should pre-create all required subdirectories in the ephemeral fallback:
if [ ! -d /mnt/state ]; then
mkdir -p /var/openclaw-state
ln -sfn /var/openclaw-state /mnt/state
fi
# Add this:
mkdir -p /mnt/state/workspace /mnt/state/sessions /mnt/state/credentials
Impact
Non-fatal — the agent works and chat is functional. BOOTSTRAP.md not persisting means the agent re-bootstraps from defaults on every replica restart. Low severity but noisy.
Related
Environment
- Azure Policy blocks
allowSharedKeyAccess: true on storage accounts
- Container app running without Azure Files volume mount
- Region:
southindia
Summary
When running with
SKIP_STORAGE=true(or when the Azure Files volume mount is removed due to Azure Policy blocking shared-key access), the entrypoint correctly falls back to an ephemeral/var/openclaw-statedirectory. However, writes to~/.openclaw/workspace/BOOTSTRAP.mdfail with aWrite failederror in the Control UI, even though other workspace files (IDENTITY.md, USER.md) write successfully.Error seen in Control UI
Steps to reproduce
SKIP_STORAGE=true(or remove the Azure Files volume mount from the container app)Root cause
The
entrypoint.shcreates the symlink/mnt/state -> /var/openclaw-statewhen the volume isn't mounted, but only creates the top-level directory. It does not pre-create theworkspace/,sessions/, orcredentials/subdirectories inside the ephemeral path.OpenClaw's write tool appears to use an atomic write pattern (write to temp file, then rename into target directory). When
workspace/doesn't exist under/mnt/state, the rename target's parent doesn't exist and the write fails. Other files like IDENTITY.md succeed because they are written directly to~/.openclaw/workspace/(not via the/mnt/statepersistence path), while BOOTSTRAP.md goes through the state-sync path.Expected behaviour
entrypoint.shshould pre-create all required subdirectories in the ephemeral fallback:Impact
Non-fatal — the agent works and chat is functional. BOOTSTRAP.md not persisting means the agent re-bootstraps from defaults on every replica restart. Low severity but noisy.
Related
SKIP_STORAGEflag is documented as a workaround for Azure Policy restrictions on shared-key storage accessEnvironment
allowSharedKeyAccess: trueon storage accountssouthindia