Troubleshooting and best practice

Network issues

• Make sure that your network allows inbound traffic on all the necessary ports for Exasol.

  For more details, see Firewall and port settings.

• The hosts must be able to communicate with each other over SSH. For more details, see Configure SSH.

• The IP addresses of the nodes must be in the same subnet. For example: 10.0.0.11, 10.0.0.12, 10.0.0.13, 10.0.0.14

• The IP addresses must be static. If DHCP is enabled in the network, the IP addresses for the hosts must be reserved.

• Make sure the nodes are synchronized with an NTP server.

For more information, see Configure the network and Network management.

Deployment configuration is invalid

• Pay attention to the format of the configuration parameters. For example, IP addresses must be space-separated while disks must be comma-separated.

  Copy

  CCC_HOST_ADDRS="10.0.0.11 10.0.0.12 10.0.0.13 10.0.0.14"
  CCC_HOST_DATADISK=/dev/mapper/exasol_disk_1,/dev/mapper/exasol_disk_2

Storage setup

• The storage devices must not contain a file system. The database stores persistent data using block storage with a specific structure for Exasol databases. If there is already a file system on the disk, the installation will fail.

• The naming and order of the block storage devices must be identical on all nodes.

• The partition where the home directory of the installation user is mounted must have at least 20 GiB free space available for the installation.

For more information, see Prepare storage devices and Storage management.

Exasol user

• The user must have root privileges to be able to install and update Exasol. To install Exasol for a non-root user, additional configuration steps are required. For more information, see Rootless deployment.

• The system shell must allow the user access over SSH.

• The login shell for the user must be bash.

• The user must have umask set to 0022 or less. For information about how to configure umask, refer to the documentation for the operating system.

• User settings for rootless and rootful installations are incompatible. If you are reinstalling Exasol, you cannot reuse the existing user if the previous installation was rootful and the new installation is rootless – or vice versa – as that will cause the installation to fail. Delete the old user and create a new one.

For more information, see Create the Exasol user.

The c4 application is not found or does not work as expected

• The c4 binary must have the executable bit set. If you download c4 from Exasol Downloads, you must run the command chmod +x <path to c4> after downloading c4. If you download c4 from the command line, make sure to include chmod +x in the command. For example:

  Copy

  wget https://x-up.s3.amazonaws.com/releases/c4/linux/x86_64/4.29.9/c4 -O c4 && chmod +x c4

• Unless you have c4 in your PATH, you must prefix all c4 commands with the path to the c4 executable – for example, ./c4 <command>

  To know how to add c4 to your PATH, refer to the documentation for your operating system.

• The version of c4 used for installation must be compatible with the Exasol database version that you install. The latest version of the database is always compatible with the latest version of c4. If you are installing a different Exasol version, see the following table to find the matching c4 version.

  Exasol database and c4 version matching

  Exasol database version	Required c4 version
  2026.1.2	4.29.10
  2026.1.1	4.29.9
  2026.1.0	4.29.7
  2025.2.1	4.29.0
  2025.2.0	4.29.0
  2025.1.16	4.28.9
  2025.1.15	4.28.9
  2025.1.14	4.28.9
  2025.1.13	4.28.8
  2025.1.12	4.28.8
  2025.1.11	4.28.8
  2025.1.10	4.28.7
  2025.1.9	4.28.7
  2025.1.8	4.28.5
  2025.1.7	4.28.5
  2025.1.6	4.28.5
  2025.1.5	4.28.5
  2025.1.4	4.28.4
  2025.1.3	4.28.4
  2025.1.2	4.28.3
  2025.1.1	4.28.3
  2025.1.0	4.28.2
  8.34.0	4.25.0
  8.33.0	4.24.3
  8.32.0	4.23.0
  8.31.0	4.20.0
  8.29.13	4.19.12
  8.29.12	4.19.12
  8.29.11	4.19.10
  8.29.10	4.19.7
  8.29.9	4.19.6
  8.29.8	4.19.5
  8.29.7	4.19.4
  8.29.6	4.19.3
  8.29.3	4.19.2
  8.29.2	4.19.0
  8.29.1	4.19.0
  8.29.0	4.19.0
  8.28.4	4.17.5
  8.28.2	4.17.4
  8.27.0	4.16.0
  8.26.1	4.15.0
  8.26.0	4.15.0
  8.25.0	4.14.1
  8.24.0	4.13.0
  8.23.4	0.4.12
  8.22.0	0.4.11
  8.21.0	0.4.11
  8.20.0	0.4.10
  8.18.1	0.4.10
  8.18.0	0.4.10

Nodes in the deployment never reach stage d (database reachable)

./c4 ps
      N  PLAY_ID   NODE  MEDIUM  INSTANCE     DB_VERSION  EXTERNAL_IP     INTERNAL_IP  STAGE  STATE    UPTIME    TTL
  ┌─  1  c3275f84  11    host    -            2025.1.0    203.0.113.11    10.0.0.11    c      running  03:50:12  +∞
  │   1  c3275f84  12    host    -            2025.1.0    203.0.113.12    10.0.0.12    c      running  03:50:13  +∞
  │   1  c3275f84  13    host    -            2025.1.0    203.0.113.13    10.0.0.13    c      running  03:50:13  +∞
  └─  1  c3275f84  14    host    -            2025.1.0    203.0.113.14    10.0.0.14    c      running  03:50:13  +∞

If you are using a jump host, this may not necessarily indicate a failed deployment, since c4 will report stage a until it can reach the node over SSH to determine the following stages.

If the nodes reach stage c (COS reachable) but not d (database reachable), the reason may be that the connection between the jump host and the nodes is timing out.

To troubleshoot:

• Try connecting to the database from a client. If you can connect without issues, the deployment was successful and the incorrect status is caused by the jump host connection to the cluster.

• Connect to one of the nodes and run c4 on that node. If the issue is caused by the connection from the jump host, c4 on the node should report status d (database reachable).