Skip to main content

Netskope Help

Troubleshooting Tips and FAQs

This section provides information about common issues and suggested solutions.

The installation failed/hit a strange error. How do I get help?

Yes, please open a ticket with Netskope support and we’ll get an engineer to help you as soon as possible. Usually following the installation steps in this guide prevents most issues. If you do engage support, and you can access Cloud Exchange (the install got that far), please provide the following details with the ticket:

  • Download, install (requires ZIP command), and execute the Diagnose script found at

  • If you have already installed a SSL certificate, two of the commands in the diagnose script will not work. If the UI is accessible:

    • Copy the exact version of cloud exchange and its components in use by CE. Go in your CE instance as follows: Go to Settings > General tab, Software version section.

    • Download the application's logs from your CE platform. Navigate to the Logging tab and click on the download icon.

  • Attach all output to the support ticket.

There was an issue while checking the podman-compose version. What should I do?

For issues when checking for installed podman-compose version, you can reinstall podman-compose by running this command: sudo pip3 install podman-compose.

I got a Bad Gateway error. What could cause this?

There are 3 possible causes:

  1. Mongo data directory permission issue

  2. The Core/Mongo-DB container is down

  3. The CE maintenance password is incorrect

For the Mongo data directory permissions issue


Execute ls -lRn . inside the directory with docker-compose.yml.

The mongo-data dir should be read/write accessible to the user with UID 1001.

total 0
drwxr-xr-x. 3 1001 0 16 Apr 14 18:16 data

Solution to mongo data directory permissions issue:

Execute the setup script again using ./setup to fix the file permissions.

Restart CE.

For the core/mongo-db container is down issue


Check the container status using sudo docker-compose ps, all the containers should be Up.

$ sudo docker-compose ps
Name Command
State Ports
ce_330_core_1 /bin/sh Up 80/tcp
ce_330_mongodb-primary_1 /opt/bitnami/scripts/mongo ... Up>27017/tcp ce_330_rabbitmq-stats_1 /opt/bitnami/scripts/rabbi ... Up 15671/tcp,>15672/tcp, 25672 /tcp, 4369/tcp, 5551/tcp, 5552/tcp, 5671/tcp,>5672/tcp
ce_330_ui_1 /bin/sh Up>3000/tcp, 80/tcp ce_330_watchtower_1 /watchtower --http-api-update Up>8080/tcp

Solution to core/mongo-db container is down:

If any containers are down follow the below steps:

sudo docker-compose down
sudo ./start
For the maintenance password is incorrect Issue


Check the core logs using `sudo docker-compose logs core` for any "authentication error".

Check if the customer is using CE version 3.2.0 or below 3.2.0 with the same MongoDB.

Solution to the maintenance password is incorrect:

Perform the following steps:

sudo docker-compose down
sudo rm -rf .env
sudo ./setup
Add maintenance password as "cteadmin"
sudo ./start
Receiving error during SSO setup when entering hostname (without a Top Level Domain). Why?

SSO requires a top level domain (TLD). Not adding a TLD in the hostname while mapping the URL and upon enabling SSO in CE, a customer will receive the error "Invalid Hostname, Top Level Domain required". This is resolved by adding proper TLD e.g. (

"Unsupported TLS Protocol Version Error" appears. Why?

If you receive this kind of error then it's because Netskope CE by default supports TLSv1.3 only. To resolve this error, you should allow Netskope CE to run on TLSv1.2 along with TLSv1.3 and for that you have to change the TLS version from the setup script. Re-run the setup script again and give ‘Yes’ to following question.

Do you want to enable TLSv1.2 along with TLSv1.3 for CE UI.

Then execute the start script.

Cloud Exchange certificates are expired. How do I fix this?

If your certificates are expired then follow below steps to regenerate the certificates.

  • Down all the containers.

  • Remove the certificate files (cte_cert.crt, cte_cert_key.key) from data/ssl_certs folder.

  • Re-run the setup script to regenerate the certs. Enter “https” to the below question:

Do you want to access CE over HTTP, or HTTPS (HTTPS is recommended)? https
  • Execute the start script.

Although sharing is configured, the IoCs reported are not being shared with the threat source.

While sharing the IoCs to a particular plugin, the sharing filters provided with the plugin’s configurations are considered. Ensure that the sharing configuration matches with the IoCs you are expecting to be shared. If the sharing filter is incorrect, fix the sharing criteria. To fetch the historical data that you may have missed due to misconfiguration, consider removing the sharing configuration and re-adding it.

Netskope is rejecting some of the URLs Threat Exchange is pushing to it. Why?

Netskope only accepts URLs with wildcard characters that are in front of the domain, others will be rejected when Threat Exchange tries to send it. So * will be accepted by the Netskope tenant,but* will not. If your Threat Exchange database contains wildcards, you will need to manually tag to share.

Can I create new users apart from the default admin user?

Yes. Refer to Users.

Where are all the uploaded plugins stored?

By default, all your uploaded plugins are stored inside the ./data/custom_plugins directory. However, this can be changed from the docker-compose by mounting a different directory or the Admin can add an additional repository to download custom plugins from. This is configured within the Settings menu. This is the best method of adding additional plugins to your CE instance, and the only method for adding additional CTO, CLS, and CRE plugins.

How do I reset the user password if the current password is forgotten?

To reset the administrator password, refer to Reset Password in the Account Settings section. Make sure to change the password from Account Settings after the CE administrator has reset the password.

To reset any other user’s password, the Super Admin can update a user password from Settings > Users, and then click the Edit icon on the right.

CE shows numerous errors after it was successfully setup (fetching error, internal server error, etc.)

A special character was potentially used for the maintenance password during setup, which RabbitMQ does not support and causes issues with other services attempting to schedule tasks as cross-container communication fails to engage RabbitMQ.

Run the following steps from the directory where docker-compose.yml resides to reconfigure the maintenance password:

sudo docker-compose down
sudo rm -rf .env
sudo ./setup
Add maintenance password.
sudo ./start
The IoCs search performance is slow. It takes more than 5 seconds to load results.

The platform by default searches for the last 7 days of IoCs. If there are too many IoCs (more than 1 million) and no filter selected, the search performance will be slow.

Proposed solution : Consider applying the filters and narrowing the search criteria. Performance is best when the data set is ~100K records or less.

After upgrading/restarting the core and ui containers, the custom plugin configurations are not visible.

Verify you uploaded a custom plugin with active configuration to Netskope CE prior to upgrading or restarting the containers. In such a case, upload the custom plugin after the upgrade (Refer to Create a Custom CTE Plugin in the Supported 3rd-party Plugins). The configurations would be retained after uploading the custom plugin and normal operation is restored.

While configuring a new plugin, even after providing accurate credentials, the configuration is not saved and an error message is displayed.

Verify if the outgoing API calls require a proxy. If your network deployment expects proxy for HTTP API calls and proxy is configured, the plugin operations would be impacted.

Proposed Solution:

  • Go to Settings > Proxy.

  • Edit the existing configuration and enable Use System Proxy.

Although the Poll interval for a plugin is configured to poll every 5 minutes, the Last Run shows an interval which is more than 5 minutes ago.

CE relies on an internal scheduling mechanism for the plugin's task. There are workers which execute the plugin tasks, by picking up a task from the queue one by one. The number of workers available in your system depends on the number of cores. If the available workers are busy serving plugin task, the already queued up task has to wait till the existing worker is available. This situation may usually occur during initial data ingestion, where there’s more data to be processed.

Proposed Solution: Consider increasing the cores of the system if you have a large number of configured plugins, and the configured plugins are consistently lagging behind. For initial ingestion, the system should pick up the backlog post initial ingestion and behave normally if the incremental data is not large.

A plugin configuration shows a red alert icon as shown below. What happened?

If there is a red alert icon on one of the configurations, it indicates that there was one or more problems while polling the plugged-in system for data per that configuration. This could be related to API, proxy, or SSL settings.

Proposed Solution:

  • Make sure the Plugin Configuration has correct parameters for API, Secret key, URL, etc.

  • Make sure Enable Proxy is selected and your proxy is configured if outbound network calls require a proxy connection.

  • Check logs for errors occurring around the last run time displayed on the configuration from the Audit section.

Mac OS users cannot select tar.gz while uploading a custom Threat Exchange plugin via the Add Plugin widget

When a user tries to upload a plugin with tar.gz package with the browse button, tar.gz files are not selectable by default.

Proposed Solution:

  • Drag and drop plugin packages to the drop area of the UI.

How do I update the last run time of a plugin configuration? This is to replay the indicators in case they were missed.

Open the plugin configuration and set the Last Run value to an older date-time and save the configuration. Make sure that the configuration is currently not running when you update the Last Run value.

What kind of indicators are extracted from STIX/TAXII sources?

For STIX 1, the cybox observables of type URI, Domain, SHA256 and MD5 are extracted. For STIX 2, the same type of observables are extracted from the pattern string field of the indicators.

Even though a file in the repo is renamed, the comment on indicator still reflects the older file name.

This is a known limitation. Indicator comment is only added the first time that file is encountered. In subsequent runs, if the file is renamed, only the external hits will be increased as long (as the contents of the file remains same).

Ticket status is showing Deleted within Cloud Ticket Orchestrator even though tickets/incidents are not removed from 3rd-party platforms. Why?

This may happen if the API credentials used to create the tickets do not have access to the tickets anymore. Make sure that the credentials you are using have read access to the tickets.

How do I handle large repositories with the Github DLP Plugin?

When a Git repo contains a large number of files, a plugin configuration could timeout. The default timeout duration is set to 120 minutes. However, this can be increased by adding an environment variable in the docker-compose file.

    image: crestsystems/netskope:core-latest
    container_name: "core"
    - ./data/custom_plugins:/opt/netskope/integrations/cte/custom_plugins:z
Log Shipper restarted or stopped. Why?

Log Shipper stops if something breaks, typically because one of the following conditions are considered a failure: code race condition, core dump, process errors, or TCP socket errors. If CE receives 5 of these, it stops. Note that Log Shipper does NOT restart when it receives API errors, including the HTTP 200 error code, Response: {"status":"error","errorCode":"General Error","errors":["We encountereda backend error. Please try again."]}

Could not find the plugin with id = *****.

When updating the plugin from Settings > Plugin Repository, the plugin code is getting updated but it is not reloaded, which is causing this error. Try to restart the docker services using the command docker-compose restart to resolve the issue.

An error occurred while enabling SSO configuration.

When you see this message: Error URL host invalid, Top Level Domain required, it's typically because the domain name used for accessing CE does not have TLD. To resolve this, use a hostname with TLD.

After rebooting the server/VM containers are not starting.

Containers not starting after rebooting the server/VM is due to the restart: on-failure:5 tag in the docker-compose.yml file. To resolve this, change tag value as restart: always” in the docker-compose.yml file.

Getting a Bad Gateway error even if I do a docker-compose rm and reinstall it.

A Bad Gateway error appears due to mongo-data folder permissions not being properly set. Copying the wrong MongoDB folder can cause a permission issue to occur. To resolve this, delete the mongo-data folder, recreate the folder, and copy data from the backup location.

Getting a Bad Gateway error when trying to access Netskope CE.

One of the possible reason for getting Bad gateway is the mongo-data directory is removed or the mongo-data directory does not have enough permissions. To resolve the issue:

  1. Pull the latest changes from remote: git reset –hard HEAD && git pull.

  2. Rerun the setup script: python3 setup.

Getting a Bad Gateway error when updating the UI with an older version of docker-compose.

Bad gateway error appears due to the maintenance password not being setup, which is available in latest version, but not in old docker compose version. To resolve this, do a git pull, and then run the setup script with maintenance password and restart CE.

We use static DNS servers but CE uses rotating DNS services (i.e. non-static). What can we do?

CE is designed to leverage dynamically defined DNS due to limitations of docker-compose. If you wish to have CE utilize rotating DNS services, the resolv.conf file must be customized to eliminate references to corporate DNS servers and restored after every code upgrade

To apply a workaround customers need to follow below steps:

  1. Copy the host's /etc/resolv.conf file and create a new file (copy of /etc/resolv.conf) inside the data folder of ta_cloud_exchange.

  2. Open the copied resolv.conf file and remove the corporate nameservers (which are not required or desired) and add the static nameserver that will be appended to the container.

  3. Mount the newly created resolv.conf file to the core container. Open the podman-compose.yml file and add this line inside the volumes section of the core service: ./data/resolv.conf:/etc/resolv.conf

  4. Down all the pods using the ./stop command and then again start the pods using ./start command.

Note that you will need to maintain this resolv.conf file after every upgrade as the setup script will overwrite your changes.

Follow the steps below to upgrade and maintain your file:

  1. Use this command to forcefully reset all files on Git to HEAD: git reset --hard HEAD

  2. Upgrade the CE using traditional update instructions from the documentation.

  3. The resolv.conf file from the previous CE must be moved to the newly cloned repo if the customer is cloning the new repository. If not, there is no need to create or transfer the file because it has already been created.

  4. As described in the instructions for the workaround, now open the docker-compose.yml or podman-compose.yml file and mount the data directory's resolv.conf file.

  5. Down all the containers and then again start the containers to reflect the changes.