You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 behost 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 whenupgrade.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
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:
The text was updated successfully, but these errors were encountered: