Backup restore brocken - wrong file owner "yellowtent" instead of "www-data" in /app/data Lamp Stack

[dsp76]

Description

I had some no related issues in an application installed in the LAMP stack. When I tried to restore an earlier manual and automatic backup from today, the app failed to start after the restore. I found out, that all restored files are owned by "yellowtent" instead of "www-data". Unfortunately the shell doesn't start so I can't manually fix it recursively.

Steps to reproduce

• restore LAMP App from backup
• files are owned by "yellowtent"

Logs

Jan 22 20:43:48 ==> Do not override existing index file
Jan 22 20:43:48 ==> PHP version set to 8.3
Jan 22 20:43:48 ==> Source custom startup script
Jan 22 20:43:48 touch: cannot touch '/app/data/tmp/.npmrc': Permission denied

Troubleshooting Already Performed

• tried to enter terminal to change owner of the files

System Details

Generate Diagnostics Data

Cloudron Version

Cloudron version - 9.0.17

Ubuntu Version

Ubuntu version - Ubuntu 24.04 LTS Linux 6.8.0-90-generic

Cloudron installation method

Options:

• Manual with ./cloudron-setup

Output of cloudron-support --troubleshoot

Vendor: Hetzner Product: vServer
Linux: 6.8.0-90-generic
Ubuntu: noble 24.04
Execution environment: kvm
Processor: AMD EPYC-Milan Processor
BIOS NotSpecified  CPU @ 2.0GHz x 8
RAM: 32087112KB
Disk: /dev/sda1        21G
[OK]	node version is correct
[OK]	IPv6 is enabled and public IPv6 address is working
[OK]	docker is running
[OK]	docker version is correct
[OK]	MySQL is running
[OK]	netplan is good
[OK]	DNS is resolving via systemd-resolved
[OK]	unbound is running
[OK]	nginx is running
[OK]	dashboard cert is valid
[OK]	dashboard is reachable via loopback
[OK]	No pending database migrations
[OK]	Service 'mysql' is running and healthy
[OK]	Service 'postgresql' is running and healthy
[OK]	Service 'mongodb' is running and healthy
[OK]	Service 'mail' is running and healthy
[OK]	Service 'graphite' is running and healthy
[OK]	Service 'sftp' is running and healthy
[OK]	box v9.0.17 is running
[OK]	Dashboard is reachable via domain name

[dsp76]

OK - managed to enter the terminal with recovery modus and changed ownership of the files. App is now running again. But still - whats the issue with the backup restore?

[joseph]

@dsp76 said in Backup restore brocken - wrong file owner "yellowtent" instead of "www-data" in /app/data Lamp Stack:

Jan 22 20:43:48 ==> Source custom startup script
Jan 22 20:43:48 touch: cannot touch '/app/data/tmp/.npmrc': Permission denied

Do you have a custom /app/data/run.sh ? It seems that script is causing this error. That script runs as root though, so I am not sure why it gets permission denied.

[dsp76]

I have a run.sh indeed. Which runs invoked by start.sh, right?

I don't think there is anything that overrules the start.sh chown command.

#!/bin/bash
set -e
shopt -s expand_aliases

# Alias zur Nutzung innerhalb des Skripts
alias swd='sudo -E -u www-data'

# Pfade
TMPDIR=/app/data/tmp
NPM_CACHE=$TMPDIR/npm_cache
COMPOSER_CACHE=$TMPDIR/composer_cache
NPMRC=$TMPDIR/.npmrc
BASHRC=/app/data/.bashrc

# Verzeichnisse & Dateien vorbereiten
swd mkdir -p "$NPM_CACHE"
swd mkdir -p "$COMPOSER_CACHE"
swd touch "$NPMRC"

# Rechte setzen
chown -R www-data:www-data "$TMPDIR"

# .bashrc ergänzen (idempotent)
ensure_bashrc_entry() {
  local LINE="$1"
  grep -qxF "$LINE" "$BASHRC" || printf "%s\n" "$LINE" >> "$BASHRC"
}

ensure_bashrc_entry "alias swd='sudo -E -u www-data'"
ensure_bashrc_entry "alias php='php -d memory_limit=1G'"
ensure_bashrc_entry "export NPM_CONFIG_CACHE=$NPM_CACHE"
ensure_bashrc_entry "export NPM_CONFIG_USERCONFIG=$NPMRC"
ensure_bashrc_entry "export COMPOSER_CACHE_DIR=$COMPOSER_CACHE"

# App starten (z. B. Apache im LAMP-Stack)
# example: exec /usr/bin/supervisord -c /etc/supervisor/supervisord.conf

As far as I can see, start.sh has

chown -R www-data:www-data /app/data /run/apache2 /run/app /tmp

But still after restoring backup it all belong to yellowtent.

When I find the time, I will test this with a vanilla LAMP App...

[joseph]

@dsp76 yes, run.sh is called by start.sh .

• Cloudron downloads the backup. At this point, the users of all files are yellowtent. This is the user which Cloudron code runs as.
• Then , start.sh runs as root (from inside container)
• Which then calls run.sh

Maybe the above helps debugging further.

[james]

Hello @dsp76
Is this still an issue?

[dsp76]

@james need to test backup and restore again to find out... will do.