Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade.sh breaks for grafana user id of 472/xxx471 #284

Open
BuongiornoTexas opened this issue May 26, 2023 · 0 comments
Open

Upgrade.sh breaks for grafana user id of 472/xxx471 #284

BuongiornoTexas opened this issue May 26, 2023 · 0 comments

Comments

@BuongiornoTexas
Copy link
Contributor

Context
When I run upgrade.sh in rootless docker, the grafana docker container is set up to run grafana as user 472 inside the container, which maps to a subuid of 100471 for my uid of 1000 in the host file system. So all of the grafana folders in Powerwall-Dashboard have a ownerships of 100471:root (which is the correct file ownership for the default grafana container setup and a container owner of 1000). NB for a different host uid, it will be host uid x 100 + 471.

Problem
When I run upgrade.sh, I run it from my user (docker rootless) id of 1000, which does not have modify permissions on the grafana folders. Consequently, I get file permission errors when upgrade.sh tries to modify any files/folders in the grafana directory - the script correctly objects to user id 1000 trying to modify files owned by user id 100471.

The script then fails catastrophically, requiring significant manual rework to recover and reset.

This happens partially because I'm running rootless and partially because Powerwall-Dashboard effectively ignores the directory permissions because the default docker runs as root, and hence can always write to the grafana folder regardless of the file ownership (not really what should be happening).

Possible solutions

  • The best long term solution would be to sort out the directory permissions so that Powerwall-Dashboard honors directory ownership. However, this may require a fair bit of rework in the underlying configuration - I'm not ready to leap into that issue just at the moment, and I can well understand this solution being pushed on the long term backlog by everyone else as well.
  • In the short term, it would be good to modify the script to check that ownership of the grafana folder is the same as the Powerwall-Dashboard folder, and if not, stop the upgrade script before taking any action and warn the user about the issue. I will get to a PR on this when I get done with the usage service. In the medium term, the script could also be updated to implement the manual fix below.

  • Manual fix:

    • Stop the dashboard.
    • Run recursive ownership change on the grafana folder to match the host user id:group of the Powerwall-Dashboard folder.
    • Run upgrade.sh.
    • Revert the grafana ownership.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant