Can't write data to Couchbase


I’m using Couchbase Community 5.0.1 and .NET SDK

When running it under IIS with a Local System user in the application pool, everything is fine.
After creating my own local user and adding it to the administrators group, when I try to create a document for example in a Couchbase type bucket, the document is created but with no content and I get Success=false from the SDK with no exception.

This reproduces for me on Windows Server 2016.
It didn’t reproduce on Windows 10

What could be the problem?

My suspicions would be either server security settings requiring TLS for all network communication except on Local System, or a restrictive .NET security profile. Sorry, I know that’s not much to go on.

A couple questions:

  • Which API are you using to create the document? Any quick pseudocode example?
  • Did you have a look at the logs around the time of the issue and is there anything seemingly related? The reason I ask is sometimes a failure may occur on a different thread. Usually this will come back in the response and exception, but maybe something different happened here.
  • Is there a reason you’re using such an old SDK? That’s not likely the cause, but you should be able to update to the latest in the 2.x series as it’s all API compatible. 2.5.8 was back in March of 2018. The current release is 2.7.17 as of today’s writing. That might get you some more information.
1 Like

I think I’ve just found the issue.

I’m passing encrypted data to Couchbase using windows’ DPapi.
For some reason on Windows server 2016 the encryption fails which results in Null being sent to Couchbase.

So I think it’s clearly not a Couchbase issue

1 Like

And not that its related to Couchbase but just in case anyone stumbled on this thread, to be able to encrypt data using .NET’s ProtectedData class after changing the app pool’s user to a local user, it’s needed to also set “Load user profile = true” in the IIS application pool otherwise you will get the following error:

" The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread’s user context, which may be the case when the thread is impersonating.