Port 8091

[Zee Palmer]

NotesPort numbers in computer networking represent communication endpoints. Ports are unsigned 16-bit integers (0-65535) that identify a specific process, or network service. IANA is responsible for internet protocol resources, including the registration of commonly used port numbers for well-known internet services.

Well Known Ports: 0 through 1023.

Registered Ports: 1024 through 49151.

Dynamic/Private : 49152 through 65535.

TCP ports use the Transmission Control Protocol, the most commonly used protocol on the Internet and any TCP/IP network. TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and that packets will be delivered in the same order in which they were sent. Guaranteed communication/delivery is the key difference between TCP and UDP.

UDP ports use the Datagram Protocol. Like TCP, UDP is used in combination with IP (the Internet Protocol) and facilitates the transmission of datagrams from one computer to applications on another computer, but unlike TCP, UDP is connectionless and does not guarantee reliable communication; it's up to the application that received the message to process any errors and verify correct delivery. UDP is often used with time-sensitive applications, such as audio/video streaming and realtime gaming, where dropping some packets is preferable to waiting for delayed data.

When troubleshooting unknown open ports, it is useful to find exactly what services/processes are listening to them. This can be accomplished in both Windows command prompt and Linux variants using the "netstat -aon" command. We also recommend runnig multiple anti-virus/anti-malware scans to rule out the possibility of active malicious software. For more detailed and personalized help please use our forums.

hi eben ,

Sorry for pulling up the old thread .

How this works in N1QL query context and not cbq CLI .

Because I am having trouble with running N1QL on 8091 from my client outside CB K8s cluster .

When I see K8s cluster has no 8093 port exposed and I guess this may be the issue .

thanks

And my values.yaml (default shipped with Couchbase ) has below definition to create query service.

Any pointers where and how should I define 8093 port ? or make query service atleast up and running my pod definition ?

You're accessing the root path when you go to just port 8091 with nothing else. Anything accessing Couchbase functionality is going to add a path, so this will be dealt with by internal routing. You can see those paths if you look at the REST api docs.

It's not correct that nothing wants to access Couchbase through port 8092, either. Various services use different ports. 8092 is used for some forms of query and other purposes. You can find out more about the different ports and why you need them open in the Couchbase docs.

I've a Couchbase image. I'm running some curl commands to configure the Couchbase server and to create an admin user. Problem is, curl fails with error message Failed to connect to 127.0.0.1 port 8091: Connection refused. netstat does not show that port 8091 on the localhost is listening. those work! What am I missing?

Please use the form below to provide your feedback. Because your feedback is valuable to us, the information you submit in this form is recorded in our issue tracking system (JIRA), which is publicly available. You can track the status of your feedback using the ticket number displayed in the dialog once you submit the form.

This page describes the TCP ports that are used by Couchbase Server for network communication.Some ports, such as those used for cluster management, are required to be open on every node because they are essential to how Couchbase Server communicates with itself.Other ports are used by individual Couchbase Services, and are only required to be open on the nodes where those services are running.

Couchbase Server uses a default set of port numbers for all ports that it requires.The Couchbase Cluster Manager on each node is responsible for port management, and will open and close these ports on the host as necessary, as well as automatically switch to using encrypted ports if the cluster is configured to use TLS.Most port numbers can be remapped to fit the requirements of your network environment, but some port numbers cannot be changed.

XDCR (cluster-to-cluster): A source node connects to the port on a destination node of another cluster as part of an XDCR replication stream.(This is very similar to the client-to-node communication path.)

As of Couchbase Server Version 7.0, the XDCR protocol Version 2 (XMEM), which uses the Memcached Binary protocol, is the only XDCR protocol supported.Version 1 (CAPI), which used the REST protocol, is no longer supported.Refer to XDCR Advanced Settings for information about the XDCR protocol version and other advanced settings.

Neither the Cluster Manager nor any of the Couchbase Services will start if unable to listen on all required ports.Note that the cluster manager and all services attempt to bind to required ports using the IP address family that the Couchbase Server cluster is configured to use (see Manage Address Families).Therefore, if the Couchbase Server cluster is configured to use IPv6, the cluster manager and all services attempt to bind to required ports using IPv6; and if the cluster is configured to use IPv4, the cluster manager and all services attempt to bind to required ports using IPv4.If the cluster manager or service is unable to bind to one or more required ports using the configured IP address family, it will not start.

cbbackupmgr, the backup client, connects to the Couchbase Server using the ports listed above.You can find detailed information about the server ports in the Detailed Port Description.Below is a summary of the services cbbackupmgr is accessing via the ports.

Most, but not all, port numbers used by Couchbase Server can be remapped from their defaults to fit the requirements of your network environment.Refer to Table 2 for details about default ports and whether or not they can be remapped.

This works as intented. HOWEVER there is one user that gets occassionally a login to the internal firewall IP at port 8091. He works on a RDS server and he is the only one affected. It is not always or constant.

When it is happening and another user mails him the original end url he has no problem viewing that website. It is mostly with a partner portal website, I can add an exception not to replace e-mails from that domain but would rather understand what is wrong here.

Hello Fred_B,

Thank you for reaching out to the community, 8091 is service used by NTLM/ADSSO, check whether or not under the device access > for LAN is it enabled ? if yes then disable and check the results again !

I was replacing the default certificate with our created certificate editing the https port 8091 of command central. Just after providing the location of .jks file I mistakenly saved it without replacing the correct keystore password. Now server is only listening on 8090 (http) port but not on 8091(https).

I thought to login with http port 8090 and correct the configuration but server is getting redirected to 8091 and admin page of command central is not opening. Could you please let me know how to fix this issue.

As Holger stated, please recover the https connector either by restoring the default certificate or better provide the correct password of the custom certificate in the *-defaultHttps-8091.properties file, under the @secure.keystorePass property.

Command Central WebUI is always redirected to open on https for security measures.

I have changed the tomcat default port to 8091 (eg. :8091/project) which has been set up in intranet server and is working very fine within the network.I have to provide access to the application (only to port 8091) to some users outside the network or some IPs in the network.what could be the solution ?

Check your tomcat server.xml configuration file and ensure that you have not configured it to listen only on localhost (127.0.0.1) i.e. look for an entry address="" in your connector definition and remove it. This explains why it works in the same host when you access it with :8091/project

Solution:

Port 8091 may be blocked by the Intel Services Manager program. The process (serviceManager.exe) must be stopped and the Desktop Service can be installed. The Intel Services Manager searches for another port when restarting.

This behavior also occurs if the Rec Solution Server services are located on the same server / workstation. Since it is not possible to change the port of DWDesktop, the port of the Rec Solution Server services must be changed.

Yes, i can firewall this, however i want to make security properly implemented. however i cant find any documentation how to bind 8091 only to localhost. In the apache/nginx config its only explained for the 8090 port which you can see i have done.

@Najjar _Innovura_ please read my post ... synchrony is listening on the public IP and not localhost , this is my whole issue (out of the box) which i want to fix. I don't like having open services that are unnneeded.

And synchrony comes out of the box running on port 8091 and should not be opened publicly since users (client machine) communicate with Synchrony through Confluence Tomcat Server and confluence contacts synchrony internally.

currently I'm struggeling in defining multible entrypoints. Basicly I want to listen on port 443 and 8090.

My old rev proxy is running on NGINX and I want to recreate the rule according to my config. I'm not sure how to make both entrypoints visible.

Ive had a docker container fail to start like this where a stopped or deleted container is somehow still bound to port and prevent container start. Maybe it took 1 or 2 reboots of host, i forget, but ultimately docker will show bound container as running or correctly shows it as stopped and allows container start.

3a8082e126