4

I'm aware that Mist cannot connect to a geth node in another computer, but how about to a geth instance running in the same computer but under a different user?

My goal would be to have Alice and Bob run the same wallet (via Mist) in the same Linux box, but the geth always be running under the hood in the background when the computer starts, so that the blockchain is always in sync without the need of leaving the Mist UI open 24/7.

For that, I created a user called geth, and created a shared folder called /home/shared which will hold the .ethereum subfolder. Then I make these symlinks for all users:

/home/geth/.ethereum -> /home/shared/.ethereum
/home/alice/.ethereum -> /home/shared/.ethereum
/home/bob/.ethereum -> /home/shared/.ethereum

Then I run geth by doing:

sudo runuser -l geth -c 'nohup /home/shared/Ethereum-Wallet-linux64-0-8-1/resources/node/geth/geth > /home/geth/geth.log 2>&1 &' &

And it seems to run and sync well. The problem is when I try to run Mist inside alice's or bob's session, it gives:

[2016-08-06 15:02:36.604] [INFO] Sockets/node-ipc - Connect to {"path":"/home/alice/.ethereum/geth.ipc"}
[2016-08-06 15:02:36.621] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:37.623] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:38.624] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:39.626] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:40.626] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:41.628] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...
[2016-08-06 15:02:42.630] [WARN] Sockets/node-ipc - Connection failed, retrying after 1000ms...

I thought it was a permissions problem, but I created a unix group called family, put all users in it (geth, alice and bob), and gave enough permissions for all to read the ipc file, proof:

$ ls -lha /home/alice/.ethereum/
total 496K
drwxrwx--- 6 alice family 4.0K Aug  6 14:58 .
drwxrwsr-x 5 alice family 4.0K Aug  5 17:19 ..
drwxrwx--- 2 alice family 468K Aug  6 15:16 chaindata
drwxrwx--- 2 alice family 4.0K Aug  6 14:58 dapp
srwxrwx--- 1 geth  family    0 Aug  6 14:58 geth.ipc
drwxrwx--- 2 alice family 4.0K Aug  5 12:21 keystore
-rw-rwx--- 1 alice family   64 Aug  5 11:40 nodekey
drwxrwx--- 2 alice family 4.0K Aug  6 14:58 nodes

However after making these permissions changes, it still cannot connect. What's wrong with the IPC connection?

UPDATE: Apparently, after I stop geth and run it again, it re-creates the file again but with only 600 permissions. So maybe changing the permissions after the file has been created is not enough, and I have to make geth create the file with the correct permissions? I tried to do this by doing two things:

  1. Use umask 022: this doesn't work, either by adding it in /home/geth/.profile or by adding it before the launch of geth via sudo runuser -l geth -c 'umask 022 && nohup /home/shared/Ethereum-Wallet-linux64-0-8-1/resources/node/geth/geth > /home/geth/geth.log 2>&1 &' &

  2. Using ACL: doing setfacl -d --set u::rwx,g::rwx,o::- /home/shared/.ethereum. Still doesn't work.

  3. Setting the getid of the folder via sudo chmod g+s /home/shared/.ethereum.

And it still doesn't work, geth keeps creating a 600 file in /home/shared/.ethereum instead of 660

UPDATE II: Changing the ipc file's permissions to 777 makes it work!!! Why does 770 doesn't work? I'm puzzled. I don't want to use 777 because it seems like a security risk.

:'(

$ getfacl geth.ipc 
# file: geth.ipc
# owner: geth
# group: gatecoin
user::rwx
group::rwx
other::---

1 Answer 1

3

I solved the problem, taking in account these 2 points:

  • I was using umask 022 but the correct thing would have been umask 002. However, this still doesn't work (maybe because geth hardcodes the mask when creating the socket file instead of querying the default umask for the user). As a workaround for this, I use chmod 770 on the socket file shortly after starting geth.

  • The group permissions were correct, but after adding the user to the same group as the user geth, I forgot that the user had to re-login for the change to take effect. After I restarted the computer, all permissions started working.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.