# SingleStore Tools Issues

## ISSUE: Getting Prompted for User’s sudo Password

The SingleStore Toolbox may show the following prompt when asking for the management user’s sudo password:

```
The target user alice on host host-01.example.net does not have the privileges to perform this action.
Please enter your password to proceed with sudo.  (For details, see https://docs.singlestore.com/toolbox-redir/sudo-prompt).
sudo password for alice@host-01.example.net:

```

The prompt appears when the management user (`alice` in this example) does not have sufficient privileges to perform the action requested on the host (`host-01.example.net` in this case). To try performing the action using `sudo`, enter `alice`’s sudo password at the prompt.

The following are some specific cases where this may apply:

* `sdb-deploy install` requires root privileges to perform package management.
* `sdb-admin create-node` requires write access to the node install directory.
* `sdb-admin list-nodes` requires read access to the memsqlctl state file.

## How to Avoid This Prompt

If your management user should be allowed to create, delete, start, stop, or modify nodes, add the management user to the `memsql` group on all hosts. For the example above, run the following command on `host-01.example.net`:

```shell
usermod -a -G memsql alice

```

Alternatively, re-register the host with a different management user that has the proper permissions. In this example, assume `bob` is a user with the correct privileges:

```shell
sdb-toolbox-config unregister-host --host host-01.example.net

```

```output

Toolbox will perform the following actions:
  · Unregister host host-01.example.net

Would you like to continue? [y/N]: y
✓ Successfully unregistered 1 host
Operation completed successfully

```

```shell
sdb-toolbox-config register-host --host host-01.example.net --ssh bob@host-01.example.net

```

```output

Toolbox is about to register the following host:
  · Host: host-01.example.net
  · Localhost: false

Would you like to continue? [y/N]: y
+---------------------+------------+-------------------------+---------------+
|   Host              | Local Host | SSH address             | Identity File |
+---------------------+------------+-------------------------+---------------+
| host-01.example.net | No         | bob@host-01.example.net |               |
+---------------------+------------+-------------------------+---------------+

```

> **📝 Note**: If the host machine does not have sudo installed, use the instructions above to re-register the host with a different management user. If no user has the correct privileges, connect to the host and perform the action manually.

## ISSUE: We were unable to check whether this is an official version

A message similar to the following may be shown by `sdb-report` check:

```
✘ versionHashes ................................. [FAIL]
FAIL Get https://release.memsql.com/production/index/memsqlserver/6.7.14-fa416b0a53.json: dial tcp: lookup release.memsql.com on 8.8.4.4:53: dial udp 8.8.4.4:53: connect: network is unreachable
WARN MemSQL version 6.7.14 (commit hash fa416b0a536adcfcf95d0607be2d6086a0d58796) is present on all nodes
We were unable to check whether this is an official version
For more details, see https://docs.singlestore.com/memsql-report-redir/check-version
```

This check in `sdb-report` verifies two properties: 1. Every node in the cluster is using the same version of SingleStore. 2. That version of SingleStore was officially released publicly.

To do so, it connects to the internet and looks for version information in the SingleStore package index. If `sdb-report` cannot connect to the package index, it shows this message.

```shell
sdb-report check --only versionHashes --report-path /path/to/report.tar.gz\
```

If you expect to have internet access, this may be an intermittent network issue. Try running `sdb-report check` again. To perform only this check, use the following command, replacing `/path/to/report.tar.gz` with the path to your report:

```shell
sdb-report check --only versionHashes --report-path /path/to/report.tar.gz
```

If your machine is behind a firewall or inside an air-gapped environment, use a machine outside that environment to read the package information located at the URL in the message (`https://release.memsql.com/production/index/memsqlserver/6.7.14-fa416b0a53.json` in this example).

This is an example of official release metadata (with the `"packages"` value removed for size):

```shell
curl https://release.memsql.com/production/index/memsqlserver/6.7.14-fa416b0a53.json

```

```output

{
  "releaseID": "722ce44d-6f95-4855-b093-9802a9ae7cc9",
  "version": "6.7.14",
  "commit": "fa416b0a536adcfcf95d0607be2d6086a0d58796",
  "packages": { ... }
}
```

This is an example of an unofficial hash (with irrelevant pieces removed for size):

```shell
curl https://release.memsql.com/production/index/memsqlserver/6.7.14-abcdef1234.json

```

```output

<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>NoSuchKey</Code><Message>The specified key does not exist.</Message><Key>freya/production/index/memsqlserver/6.7.14-abcdef1234.json</Key>...</Error>
```

## ISSUE: Failed to add user to the memsql group.

```
✘ Failed to add alice to the memsql group. See https://docs.singlestore.com/memsql-deploy-redir/memsql-group for more details.

```

This message appears during `sdb-deploy install` if it fails to add the management user to the `memsql` group.

During installation, the `singlestoredb-server` Debian and RPM packages create a `memsql` Linux system user and `memsql` Linux system group if they don’t already exist. These used to enforce filesystem permissions on node data and configuration.

The `memsql` user is allowed to create and delete nodes, start and stop nodes, and update node configuration. It is automatically part of the `memsql` group.

Users in the `memsql` group are allowed to list nodes, read node configuration, and run SQL statements on nodes.

When using `sdb-deploy` to install `singlestoredb-server`, it will automatically try to add the management user to the `memsql` group on each host. This allows the rest of the SingleStore Tools to manage SingleStore nodes without requiring elevated privileges. If this fails, the other tools (such as `sdb-admin` and `sdb-report`) may prompt for the management user’s sudo password when trying to run commands.

To avoid needing a sudo password for every command, add your management user to the `memsql` group on all hosts. For example, if the management user is `alice`, run the following command on each host:

```shell
usermod -a -G memsql alice
```

## ISSUE: memsqlctl is configured to require that users be in the “memsql” group for read access

```
memsqlctl is configured to require that users be in the 'memsql' group for read access. Please rerun the command as a user in this group or the root user.

```

This message appears during any `memsqlctl` command if the current user is not in the configured management group.

The [memsqlctl config file](https://docs.singlestore.com/db/v9.1/reference/configuration-reference/cluster-config-files/singlestore-server-config-files.md) can be configured to restrict access to a single Linux user and that user’s primary group. When using `singlestoredb-server` Debian and RPM packages, this is set to `memsql`, which is the system user created by the package to run SingleStore.

There are multiple options for resolving this issue:

* Run the command again as the configured user (`memsql` in this example).
* Run the command again as root or with `sudo`.
* Change the management user by editing the `memsqlctl` config file and changing the owner of all SingleStore-related files and directories.

***

Modified at: November 22, 2022

Source: [/db/v9.1/reference/troubleshooting-reference/singlestore-tools-issues/](https://docs.singlestore.com/db/v9.1/reference/troubleshooting-reference/singlestore-tools-issues/)

(An index of the documentation is available at /llms.txt)