28

Update: I got it working now. Jim Zajkowski's answer helped me detect that my /etc/init.d/couchdb reboot calls weren't actually rebooting the instance. After I manually killed the CouchDB processes and started a new instance, it picked up the required BindAddress change.

I have installed CouchDB via

aptitude install couchdb

From my server, I can connect via

telnet localhost 5984

and execute RESTful commands. When I try to access the server from another machine on our network or from a machine external of our network, I get a The connection was reset error. I've set up port forwarding on the router, and the server is otherwise accessible via Apache, Tomcat, SSH, etc.

I'm new to Linux/Ubuntu, so I wasn't sure if there was a default firewall blocking the connection, so I ran:

iptables -A INPUT -p tcp --dport 5984 -j ACCEPT

but it didn't help.

Here is the dump from running iptables -L -n -v

Chain INPUT (policy ACCEPT 2121K packets, 1319M bytes)
 pkts bytes target     prot opt in     out     source               destination
   70  3864 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5984
    9  1647 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1708K packets, 1136M bytes)
 pkts bytes target     prot opt in     out     source               destination

I assume the bytes showing as transfered for 5984 are due to my localhost connection.

Here is the dump from running netstat -an | grep 5984

tcp        0      0 127.0.0.1:5984          0.0.0.0:*               LISTEN

I configured couch.ini to have "BindAddress=0.0.0.0" and rebooted, so it should be listening on all interfaces. When I run "sudo /etc/init.d/couchdb stop" then run netstat, however, I still see the above entry. It looks like CouchDB isn't actually stopping at all. This may explain my problem, because it means it may mean that CouchDB never actually rebooted and never picked up the BindAddress change.

I manually killed the CouchDB process and started it up again. Now netstat shows:

 tcp        0      0 127.0.0.1:5984          0.0.0.0:*               LISTEN
 tcp        0      0 127.0.0.1:5984          127.0.0.1:35366         TIME_WAIT

I still can't connect though, even from another machine on the LAN.

rcampbell
  • 1,035
  • 4
  • 14
  • 24

7 Answers7

34

What does netstat -an | grep 5984 say? Does it say 127.0.0.1:5984 or *:5984? If it's 127.0.0.1, then couchdb needs to be set to listen to either all interfaces.

Jim Zajkowski
  • 1,604
  • 12
  • 11
  • 3
    "tcp 0 0 127.0.0.1:5984 0.0.0.0:* LISTEN" is the result. I configured couch.ini to have "BindAddress=0.0.0.0" and rebooted, so it should be listening on all interfaces. Here's the strange part though: when I run "sudo /etc/init.d/couchdb stop" then run netstat, I still see the above entry. It looks like CouchDB isn't actually stopping at all. This may explain my problem, because it means it probably never rebooted, and probably never picked up the BindAddress change – rcampbell Oct 30 '09 at 10:01
  • 3
    yep, I was running as a background process. it worked for me once i killed couchdb using couchdb -d and restarted it – Kristian Apr 03 '12 at 06:10
  • 2
    This answer helped me! I wanted to share that **one may easily change this setting using the Futon web interface, without having to find and edit the actual config file on disk**. Just navigate to `127.0.0.1:5984/_utils/config.html` (or equivalent URL for your setup) and double click the option value, edit, then click the green check mark. – Steve Benner Jun 19 '15 at 23:26
  • @SteveBenner Unfortunately 127.0.0.1:5984/_utils/config.html doesn't bring anything! – Dr.jacky Jul 07 '15 at 04:52
  • @rcampbell Where is couch.ini ?! – Dr.jacky Jul 07 '15 at 04:58
  • @Mr.Hyde Futon must be installed and running, in which case you acces it at the path `/_utils`. From the main Futon page you can navigate to the config section via the link on the right. Note that your base URL and port can vary depending on your CouchDB setup and system. – Steve Benner Jul 27 '15 at 00:41
16

You have to change the bind_address in /etc/couchdb/default.ini. Then restart the service and try again.

filtenborg
  • 161
  • 1
  • 2
7

I noticed that in order for this to work you must manually kill the running erlang process for some reason.ps ax | grep beam ought to reveal the erlang process, you should get something along lines of 0:00 /usr/lib/erlang/erts somewhere in the output. If you kill this process and then run /etc/init.d/couchdb restart the new config file will be loaded.

user54291
  • 71
  • 1
  • 1
  • same for me - only after killing the beam process, then do the couchdb -d, and then service stop/start.. did the new setting take effect. – Bobby Oct 14 '12 at 15:18
4

On home PC/Mac run this command: 

ssh -L 5984:localhost:5984 YOUR-SERVER-IP-HERE

next open in your browser localhost:5984/_utils ... It works for me

Alexander Ovchinnikov
  • 283
  • 2
  • 3
  • 11
4

Configuration docs:

bind_address

If you change it from the Futon configuration panel, you don't have to do anything else (rebooting the db etc.):

enter image description here

Before changing the default bind_address:

peter@earth:~/$ netstat -an | grep 5984
tcp        0      0 127.0.0.1:5984          0.0.0.0:*               LISTEN

After changing to 0.0.0.0:

peter@earth:~/$ netstat -an | grep 5984
tcp        0      0 0.0.0.1:5984          0.0.0.0:*               LISTEN

Note non-gurus: computers which cannot access yours (normally, anything outside your local network) will still not be able to access your computer (CouchDB or anything else).

Pete
  • 355
  • 1
  • 3
  • 8
  • While this answer is pretty old, it seems to lead to the right place. Futon has been replaced with Fauxton, but I think people will get the gist of changing the bind_address in the Configuration. – SMBiggs Nov 03 '16 at 06:28
2

I encountered this, and my problem ended up being that there was, apparently, couchdb already installed in my installation of Ubuntu. I had been editing the config files under /etc/couchdb, but the one that was running was in fact pulling config from /usr/local/etc/couchdb.

The tip-off was that the configs in /etc/couchdb mentioned couch 0.10, but I had just installed 1.0.1.

Matt
  • 3,241
  • 9
  • 30
  • 33
1

iptables -L -n -v will show you your current firewall rules. See if there's one that's dropping those packets before it gets to your rule.

Bill Weiss
  • 10,979
  • 3
  • 38
  • 66
  • There are no DENY rules listed in the table. Otherwise, there are three ACCEPT, one for 5984 and two duplicates for 8080. I'm not sure why there are two exact duplicates for 8080, and when I try to hit Tomcat (running on 8080) external of our network it fails, even though machines on our network can hit Tomcat fine. – rcampbell Oct 30 '09 at 09:52
  • Mind showing the output? Take your IP out if needed. – Bill Weiss Oct 30 '09 at 14:32
  • How about running `lsof -i -n -P | grep LISTEN` and posting that? You're looking for the CouchDB process, and what it's bound to. If it's `127.0.0.1:5984`, you need to configure CouchDB to listen to external connections. If it's `*:5984`, well, at least CouchDB is configured right :) – Bill Weiss Oct 31 '09 at 18:43
  • Hi Bill, sorry for not responding sooner. I've posted the raw dump you requested to the question. – rcampbell Nov 04 '09 at 10:06
  • How about that `lsof` output? – Bill Weiss Nov 04 '09 at 15:29