Cluster/bucket initialization error ("Bucket does not exist")

I was doing some tests in moving from .Net SDK 2.7.23 to 3.1.1, and I have gotten snuck trying to initialize the Cluster/Bucket.

The couchbase URL we have is:
url =

In the 2.7.23, the following configuation worked:
cc.Servers.Add(new Uri(url));
cc.UseSsl = true;
(this was with password set on the bucket options)

In the 3.1.11, I’ve changed to the following, but it always errors out (at “_Cluster.BucketAsync(bucketName)”):
Uri cUri = new Uri(url);

           ClusterOptions opts = new ClusterOptions()
						.WithConnectionString(("couchbases://" + "{cUri.Host}:{cUri.Port}")
           opts.EnableTls = true;

(this is with both username and password set in the options)

I confirmed that the username, password, and bucket name are correct (and match casing) and I tried different combinations of using port, not using port (it defaults to 443 then), but am still getting the error. I also dug into the source code, and wasn’t sure if the missing “/pools” path was causing the problem. So i did some tests by hardcoding “/pools” to the end of the HostEndpoint.ToString() return value, but this also didn’t change anything.

I have read through this previous post: Bucket with name myBucket does not exist, but the solutions/info haven’t helped in this particular case.

Does anyone have an idea what else could be tried?

PS: Forgot to add that I am testing on a .Net 5.0.2 application.

1 Like

What is the error and stacktrace? Also, you only need to provide the hostname in the connection string, but looks like maybe you are using custom ports?


Error and stack trace is:

Error Couchbase.Management.Buckets.BucketNotFoundException: Bucket with name [bucketName] does not exist
at Couchbase.Core.ClusterContext.GetOrCreateBucketAsync(String name)
at Couchbase.Cluster.<>c__DisplayClass26_0.<b__0>d.MoveNext()
— End of stack trace from previous location —

Yah, the couchbase endpoint is a bit customized (the port and the “/pools” path part). Not sure if this isn’t quite supported in SDK 3.1.1 yet or if I’m not hooking things up the right way? The host name is part of the connection string “{cUri.Host}” (checked and it’s not configured as an IP address for us).

Bit more context: The Couchbase server version we are using is 6.0 and it is hosted in GKE. The permission given to the user in Couchbase is “Application Access”, bucket shows as given permission to the user, and the bucket type for the bucket is regular “Couchbase”. The Couchbase .Net SDK is referenced from a .netstandard2.0 library, which in turn is included in the .Net 5.0.2 application.

While the error is still present, I did some more testing/investigation and have a bit more details to help narrow the focus.

I have a local non-TLS enabled Couchbase server installed (6.0) and am able to successfully initialize/open the Cluster/Bucket in both SDK 2.7.23 and SDK 3.1.1 in a test tool.

The test tools are:

  • .Net 5.0.2 App referencing a netstandard2.0 library that has a dependency to SDK 3.1.1
  • .Net Core 3.1 App referencing a netstandard2.0 library that has a dependency to SDK 2.7.23

The Couchbase address is: http://localhost:8091 (default non-TLS port)

Interestingly, I did notice that including the port in the SDK 3.1.1 connection string causes an error, and it only works if the port is left out from the connection string. Setting the bootstrap http port to a fake value seems to be ignored/doesn’t impact things connecting?:

  • Not working: couchbase://localhost:8091
  • Working: couchbase://localhost
  • Working: couchbase://localhost?bootstrapHttpDirectPort=1234
  • Working: couchbase://localhost and set opts.BootstrapHttpPort=1234 (where opts is a Cluster options instance)
    [unsure if the above behaviour is expected or a bug?]

With the results above, I switched to testing against a TLS enabled connection. Unfortunately, I don’t have TLS setup on my local Couchbase (unsure if I can/how to configure this?), so I had to use the Couchbase instance that is in GKE (TLS enabled). Another complication is I can’t connect the test tools directly to the cloud Couchbase instance (I need to check whether I can/need to install a cert and/or if it’s some config on my machine), so to test, I had to deploy a service with the code and see if the Couchbase initialization calls succeed.

Given the results from the non-TLS test, I tried the TLS equivalent, but unfortunately the same error persists in all combinations I can think of:

  • Not working: couchbases://cbhost:18091
  • Not working: couchbases://cbhost
  • Not working: couchbases://cbhost?bootstrapHttpSslPort=18091
  • Not working: couchbases://cbhost and set opts.BootstrapHttpPortTls=18091 (where opts is a Cluster options instance)

From what I read/can tell, we are using a default port for TLS (18091), but unfortunately looks like leaving it out of the connection string doesn’t seem to solve the issue.

I have one more update. Decided to try this, and it connected successfully:

  • Working: couchbase://cbhost (useSSL option left to disabled)
  • Working: couchbase://cbhost (useSSL option set to enabled)

I can’t really tell what is going on from the above results (is it connecting to the non-TLS connection? is it using TLS via the default 18091 port even though the connection string and useSSL has indicated non-TLS? is the useSSL flag not honoured?).

I need to check whether our Cloud Couchbase has disabled non-TLS connections. If so, then I guess it is connecting via TLS properly, but the connection string/configuration has some caveats? If non-TLS is still enabled, then it may be using that connection.