Setting DontCheckOSXFUSE true does not seem to work

From @DavidBooher on Wed Jan 27 2016 00:44:43 GMT+0000 (UTC)

Version: 0.3.10
Fuse: 2.8.3

jimbo:.ipfs dbooher$ ipfs config DontCheckOSXFUSE true
jimbo:.ipfs dbooher$ ipfs daemon --mount
Initializing daemon…
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/172.16.144.1/tcp/4001
Swarm listening on /ip4/172.16.144.1/tcp/4001
Swarm listening on /ip4/192.168.22.200/tcp/4001
Swarm listening on /ip4/192.168.22.200/tcp/4001
Swarm listening on /ip4/192.168.89.1/tcp/4001
Swarm listening on /ip4/192.168.89.1/tcp/4001
Swarm listening on /ip4/73.44.241.86/tcp/15950
Swarm listening on /ip4/73.44.241.86/tcp/64096
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
18:37:36.343 ERROR swarm2: swarm listener accept error: peerstream listener failed: accept tcp 0.0.0.0:4001: use of closed network connection swarm_listen.go:129
18:37:36.343 ERROR swarm2: swarm listener accept error: peerstream listener failed: accept tcp 0.0.0.0:4001: use of closed network connection swarm_listen.go:129
Error: config key invalid: DontCheckOSXFUSE %!s(bool=true)
You may be able to get this error to go away by setting it again:

ipfs config DontCheckOSXFUSE true

Either way, please tell us at: http://github.com/ipfs/go-ipfs/issues

jimbo:bin dbooher$ ipfs config DontCheckOSXFUSE true
Error: Failed to set config value: Wrong config type, expected bool (maybe use --json?)
jimbo:bin dbooher$


Copied from original issue: https://github.com/ipfs/support/issues/18

From @RichardLitt on Thu Mar 10 2016 18:33:16 GMT+0000 (UTC)

I am not sure what is going on here. Ping @whyrusleeping.

From @frerepoulet on Mon Apr 25 2016 14:27:54 GMT+0000 (UTC)

fyi: having the same issue on Mac OS X 10.11.4, ipfs 0.4.0 installed via brew install ipfs

From @whyrusleeping on Mon Apr 25 2016 18:19:48 GMT+0000 (UTC)

hrm… thats very strange. Try running:

ipfs config --json DontCheckOSXFUSE true

Theres obviously a bug in the checking code, but that should at least correctly set the config var