There appears to be a constraint on the owner id number of the torrc.default file not reflected in the instructions

[jamesfpb]

Excellent explanations and instructions - thank you!
This is the first comprehensive guide that allowed me to successfully set up nodes on Docker using Tor.
I successfully set up nodes on a Synology NAS with external SSD.

One small issue with the Tor instructions:-
I found that it was not enough to have a common group id number between the torrc.default file and the Tor container.
I could only make the Tor container run correctly if the user id numbers also matched.
Suggest small update to instructions to reflect this assuming the sensitivity more widespread than just my experience.
(After finding this Tor sensitivity, rather than tinker with the other services, I just edited to use common group id number AND user id number for all containers with the userid number passed in as a parameter just as the group id number is in your version. While this may not have been necessary for all containers, it did not hurt and allowed for greater consistency)

[reverse-hash]

Hi @jamesfpb ,

To be honest, I have always deployed the nodes on new machines and probably, the ids have always matched.

I will review the Tor documentation to see if we have any other options and I will update the documentation accordingly.

Thanks for sharing this issue.

[reverse-hash]

I cannot find any reference or mention to that requirement. Also I was trying to simulate the issue but is not repicable...

# ls -n
total 4
-rw-r--r-- 1 1000 1099 303 Jun 12  2023 torrc.default
# chown nobody torrc.default 
# ls -n
total 4
-rw-r--r-- 1 65534 1099 303 Jun 12  2023 torrc.default
# exit
$ cd <repo>
$ docker-compose up -d tor
// ...
Jun 04 19:58:55.772 [notice] Read configuration file "/home/tor/torrc.default".

Can you think what it might be? Could it be something of the host machine?

[jamesfpb]

Thanks for your reply!
So it turns out my fix was better than my issue report!

I went back more thoroughly to explore removing and adding back the specific user id assignment in the Dockerfiles. Unfortunately I had it completely the wrong way round in my first report - apologies:

• The Tor container does work with userid not assigned a specific value in the Dockerfile
• However both the Bitcoin and the Electrs containers give permission denied errors trying to open their respective config files when the userid is not assigned in the Dockerfiles eventhough the assigned group id of the file is the same as the one assigned for the container user
• Weirdly for these containers, when the userid is assigned in the Dockerfiles, I can change the owner of the config files so that it does not match the container user id (as you did in your reply) and the containers still run fine

I’m working on a Synology NAS which does some functions including user management a bit differently to other Linux so it’s possible that it’s unique to my situation:.
My host user and host user group are nodebg and nodebgs and I’m using 1033 and 65537 as container user and group ids.

• Id nodebg → uid=1033(nodebg) gid=100(users) groups=100(users),65537(nodebgs)

Thanks for your further thoughts. No worries if it’s a dead end. Learning all the time…

[jamesfpb]

P.S. This Dockerfile for a Monero node also sets the user id for the container
https://github.com/sethforprivacy/simple-monerod-docker/blob/main/Dockerfile
There is reference in the readme to this being important on Synology NAS
https://github.com/sethforprivacy/simple-monerod-docker/blob/main/README.md#running-as-a-different-user

[reverse-hash]

Hi @jamesfpb

Thanks for sharing so detailed info. I was reviewing everything and I think your suggestion is the way to go:

• Add the user id as a custom param for for all containers
• Mention in the documentation your experience as a hint.