-
Notifications
You must be signed in to change notification settings - Fork 8
FAQ
fatal mkdir /root/.mole: permission denied
or
fatal stat /root/.mole: permission denied
The root cause is that sudo is setting the HOME environment variable to /root. By default, sudo should not modify the HOME from the original user's setting but there are a few configuration variables in /etc/sudoers that affect this. See the sudo man page about the -H option, env_reset, set_home and always_set_home. A possible solution is the addition of
Defaults env_keep += "HOME"
$ mole upgrade
Downloading upgrade...
fatal open /usr/local/bin/mole.part: permission denied
For mole to be able to upgrade itself the user running mole (i.e. you) must be able to write to the directory containing the mole binary. This is seldom the case for /usr/local/bin and non-privileged users. The recommended way to install mole is to keep it in ~/bin and have that directory in your PATH.
You can also create a symlink from /usr/local/bin/mole to ~/bin/mole. Mole will follow symlinks when upgrading, so even if mole was started as /usr/local/bin/mole the upgrade will work as expected.
Mole can't resolve the server name, even though everything else can:
$ mole ls
fatal Get http://foo.example.com:9443/store: dial tcp: lookup foo.example.com on 10.2.3.4:53: no answer from server
[3]
jb@jborg-mbp:~ $ ping foo.example.com
PING foo.example.com (192.168.2.3): 56 data bytes
64 bytes from 192.168.2.3: icmp_seq=0 ttl=61 time=49.001 ms
64 bytes from 192.168.2.3: icmp_seq=1 ttl=61 time=56.483 ms
^C
This is Mac OS X specific and can pop up after other VPN software has left /etc/resolv.conf in a bad state. In Mac OS X, name resolution is not normally controlled by resolv.conf. This means most everything will work fine even if resolv.conf the contains wrong information. However, due to how mole is built, mole does need correct information in resolv.conf. You will need to correct the DNS server specified in resolv.conf