How is Python Client different from .NET Client with firewalls?

I have set up two Couchbase 4.0 beta “single node clusters” on Azure. One is running on Windows, and one on Ubuntu.

The Ubuntu one has enough azure Endpoints configured that I can connect to it via the C# client and talk to it fine.

I have configured the following endpoints, as public TCP ports: 8091, 8092, 8093, 11210, 11211

C# clients can talk to it fine, but when I use Python and try to talk to that endpoint, it gives me an error code:

(<class ‘couchbase.exceptions._NetworkError_0x10 (generated, catch NetworkError)’>, _NetworkError_0x10 (generated, catch NetworkError)({‘rc’: 16, ‘message’: “HTTP Request failed. Examine ‘objextra’ for full result”, ‘objextra’: ViewResult<RC=0x10[Generic network failure. Enable detailed error codes (via LCB_CNTL_DETAILED_ERRCODES, or via detailed_errcodes in the connection string) and/or enable logging to get more information], Value=None, HTTP=0>, ‘csrc_info’: (‘src\http.c’, 140)},), <traceback object at 0x02D3F288>)

One difference apparent to me is that the Python connection bucket string is in this form:


As python code, I’m creating a bucket like this:

c = Bucket(“couchbase://host/default”)

whereas the .NET connection string is in this form:


And I open a connection to the server, then open a bucket as a second line of code.

One appears to be a REST API endpoint as a URL (8091 is the REST API port) and the other appears to be a “bucket URI syntax”.

Perhaps Python and C# are speaking to different nodes. I would suggest you enable logging in your Python client to see exactly what node it’s trying to connect to, and then post back the details. Judging from the error message, the Python client connects to the cluster (8091/11210) but fails to reach the view service (8092).

To enable logging, see

It is a SINGLE NODE cluster. So it cant be talking to different nodes. But it is a good idea to enable logging!

Okay, I think I know what the issue is.

The lone couchbase server node, only one, it’s a SINGLE NODE DEVELOPMENT SYSTEM here folks, is running on Azure. Azure VMs have a private and a public IP. The public IP in this case starts with 137.x.x.x, and the Azure datacenter IP is in the 100.78.x.x block.

I made the mistake when deploying of changing the default value for the host to 100.78.x.x, and now when I connect from Python SDK, it redirects from connecting to port 8091/8092/8093 on the 137.x.x.x address, to the equivalent ports on 100.78.x.x which is not reachable from where the client is running.

Azure endpoint mapping and the structure of the Couchbase Smart Client are at odds here.

Personally I think that the fact that a translation to a different IP address, and the fact that the different IP address is UNREACHABLE should be reflected in the Python exception itself, and not require inspection of logging to see this most basic and most important of facts. What IP is it really trying to talk to?

Logging out:

[0] <100.78.x.x:8093> (SOCK=0x0343C218) Failed: lcb_err=0x10, os_errno=138 (L:118)
[0] Connection to failed with Err=0x10 (L:226)

How do I do what the exception message states…

… Enable detailed error codes (via LCB_CNTL_DETAILED_ERRCODES, or via detailed_errcodes

I don’t see anything when I import couchbase that looks like detailed_errcodes that I could invoke.


  • Delete my dummy cluster and redeploy.
  • Put a real DNS name in instead of a real IP address when asked to give the cluster node’s Name.
  • Solve the enoaddr error during the cluster node deploy wizard by adding the local Internal Azure IP and hostname to /etc/hosts so that it all resolves properly on the node in question.

The 0x10 (‘Network Error’) is thrown when a more detailed error code could not be obtained. For older client versions, this is also thrown for any kind of network error. Starting in the C library version 2.4 more error codes were added, but in order to ensure older applications did not break, newer error codes were only enabled optionally via another option in the connection string (e.g. couchbase://host/bucket?detailed_errcodes=1).

However, the Python client already sets this for you ( Likely the problem is that the error code received is not something the client understands.

I see for example that you’re getting error code 138 via the OS, but this is not something that the C library understands, so it reverts back to the generic error.