#OpenClaw dashboard logo missing for non-sudo user install after change of gateway port

1 messages · Page 1 of 1 (latest)

dreamy siren
#

Hi all. I have an Ubuntu Desktop machine with two users, user A is sudo, user B is not sudo
OpenClaw Dashboard logo works fine for user A
Dashboard logo is missing for user B
Dashboard logo was visible for user B just after installation, but disappeared after user B change the gateway port to 18790 for her installation, so not to make port conflict with openclaw installation for user A (port 18789)

Anyone else experienced similar thing? And how to fix it?

OpenClaw_Control.png
#

openclaw gateway was reinstalled after portchange, so not have user service maintain the old gateway port.

slow viperBOT
# dreamy siren Hi all. I have an Ubuntu Desktop machine with two users, user A is sudo, user B...

This sounds like a file permissions issue. When the gateway runs under user B with a different port, it's likely looking at config/data paths that user B can't access.

Quick things to check:

  1. Config file ownership - User B's ~/.clawd/config.json5 (or wherever their config lives) should be owned by user B
  2. Data directory permissions - The gateway stores assets in ~/.clawd/data/ - user B needs read access
  3. Logo file location - The dashboard logo is served from the gateway's data directory; check if user B can access ~/.clawd/data/static/ or similar

To debug:

# Check config location for user B
ls -la ~userB/.clawd/

# Check if logo file exists and is readable by user B
find ~userB/.clawd -name "*.png" -o -name "logo*" 2>/dev/null
# 
# Test if gateway can read its own files
sudo -u userB cat ~userB/.clawd/config.json5

Likely fix:

# Make sure user B owns their config and data
sudo chown -R userB:userB ~userB/.clawd/

The logo likely disappeared because changing ports pointed user B's gateway at a config/file location that either:

  • Doesn't exist (created with wrong permissions)
  • User B can't read

Let me know what you find! 🦐

dreamy siren
#

Thanks, one question though. How can the users filepermissions be changed, just by changing the gateway port for her installation?

dreamy siren
slow viperBOT
# dreamy siren I have found something that may explain the problem. When I rightclick where th...

Found it! The logo URL is hardcoded in the OpenClaw UI as a CDN URL with a signature:

https://mintcdn.com/clawhub/4rYvG-uuZrMK_URE/assets/pixel-lobster.svg?fit=max&auto=format&n=4rYvG-uuZrMK_URE&q=85&s=da2032e9eac3b5d9bfe7eb96ca6a8a26

The s= parameter is a signature that validates the request. This signature likely:

  1. Expires after some time (time-limited token)
  2. Is bound to specific request headers/cookies from the gateway
  3. Gets invalidated when the request context changes (e.g., different port, session, or browser state)

When user B changed the port, something in the request context shifted and the CDN rejected the signature.

Quick fix: The logo should be served directly from the gateway (like /clawd-logo.png) rather than through a signed CDN URL. This is a bug in how the logo is served — it shouldn't require a valid signature to display.

For now: User B can try:

  1. Clearing browser cache/cookies for the dashboard
#
  1. Hard-refreshing the page (Ctrl+Shift+R / Cmd+Shift+R)
  2. Opening in incognito/private mode

Long-term fix: The OpenClaw dashboard should serve the logo locally rather than relying on a signed CDN URL. This would avoid signature validation issues entirely.

This is definitely worth filing as an issue! 🦐

dreamy siren
warped badge
#

I have the similar issue but in my case the gateway itself is not running anymore, tried fresh installation but same issue logo missing and gateway stops working after a while for some reason

dreamy siren
slow viperBOT
# warped badge I have the similar issue but in my case the gateway itself is not running anymor...

Different but potentially related issues here:

For the logo: Same root cause - hardcoded CDN URL with signature that expires or becomes invalid.

For the gateway stopping: This sounds like the gateway process is crashing. Check these:

# Check if gateway is running
ps aux | grep clawd

# Check journalctl logs (if running as service)
journalctl -u clawd-gateway --since "1 hour ago" | tail -50

# Check gateway logs directly
tail -50 ~/.clawd/logs/gateway.log
# 
# Check for port conflicts
netstat -tlnp | grep 18789

Common crash causes:

  1. OOM killer - gateway using too much memory
  2. Auto-update - config/schema changes breaking restart
  3. Model config issues - invalid model settings
  4. Plugin/channel crash - a specific channel causing cascade failures

Quick test for Harshit:

# Try starting gateway manually to see errors
clawd gateway start
#

The gateway should output errors before crashing - that will reveal the root cause.

For the logo fix: I'll open an issue about serving the logo locally instead of through signed CDN. The current design is fragile. 🦐