ObolNetwork / ObolNetwork/charon-distributed-validator-node
multi-client data directory permissions
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 91
- Forks
- 235
- Avg merge
- 1h 42m
- Merged PRs (30d)
- 1
Description
while incorporating vc-nimbus and vc-teku into a multi-client cluster I ran into issues with both related to permissions on the charon-distributed-validator-node/data folder. When starting the stack for the first time, Docker creates the data/ directories as root:root
Permission Requirements for Validator Client Data Directories
Different validator clients have different permission requirements for their data directories:
Nimbus
- Requires 700 (drwx------) on data directory
- Must be owned by container UID (1000)
Teku
- Requires write access to create logs directory
- May need to be owned by container UID (1000)?
work-around
modify the local charon-distributed-validator-node/data permissions as follows:
# For Nimbus
sudo mkdir -p ./data/vc-nimbus/validators
sudo chown -R 1000:1000 ./data/vc-nimbus
sudo chmod 700 ./data/vc-nimbus
sudo chmod 700 ./data/vc-nimbus/validators
# For Teku
sudo mkdir -p ./data/vc-teku/logs
sudo chown -R 1000:1000 ./data/vc-teku
sudo chmod -R 700 ./data/vc-teku
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the Docker Compose volume and data-directory setup for charon-distributed-validator-node/data, focusing on the vc-nimbus and vc-teku paths. Reproduce a first-time stack startup and compare the resulting ownership and permissions with the documented client requirements; done means both clients can create or use their required directories without the manual workaround.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, docker-compose, shell
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100