http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> How to create Users other than root...
# questions-and-troubleshooting
r
@Rocky How to create Users other than root user and give them access to individual databases
r
To create users other than the root user and grant them access to specific databases in StarRocks, you typically follow a process of creating the user, creating a role with specific permissions, and then assigning that role to the user. Here is a step-by-step guide: 1. Create a New User You can create a user using the 
CREATE USER
statement. By default, if no host is specified, it defaults to 
'%'
(any host).
Copy code
sql
-- Create a user 'jack' with a password
CREATE USER 'jack'@'%' IDENTIFIED BY 'your_password';
2. Create a Role (Recommended) While you can grant permissions directly to users, the best practice in StarRocks is to use roles for easier management.
Copy code
sql
-- Create a role for managing a specific database
CREATE ROLE db_admin_role;
3. Grant Permissions to the Role You can grant permissions on a specific database to the role. To give full access to a database (e.g., 
sales_db
), you should grant permissions on the database itself and the objects within it.
Copy code
sql
-- Grant access to the database itself
GRANT ALL ON DATABASE sales_db TO ROLE db_admin_role;

-- Grant access to all tables, views, and functions within that database
GRANT ALL ON ALL TABLES IN DATABASE sales_db TO ROLE db_admin_role;
GRANT ALL ON ALL VIEWS IN DATABASE sales_db TO ROLE db_admin_role;
GRANT ALL ON ALL FUNCTIONS IN DATABASE sales_db TO ROLE db_admin_role;
4. Assign the Role to the User Now, assign the role you created to the user.
Copy code
sql
GRANT db_admin_role TO USER 'jack'@'%';
5. Set the Default Role For the permissions to take effect automatically when the user logs in, set the role as the user's default role.
Copy code
sql
SET DEFAULT ROLE db_admin_role TO USER 'jack'@'%';
────────── Alternative: Grant Directly to User If you prefer not to use roles, you can grant permissions directly to the user identity:
Copy code
sql
GRANT SELECT, INSERT, UPDATE ON DATABASE sales_db TO USER 'jack'@'%';
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN DATABASE sales_db TO USER 'jack'@'%';
Key Privileges for Common Scenarios * Read-only access: Grant only 
SELECT
privilege. * Data loading: Grant 
INSERT
and 
UPDATE
privileges. * DDL access: Grant 
CREATE TABLE
, 
ALTER
, and 
DROP
privileges. Note: Only users with the 
user_admin
role (like the default 
root
user) have the privilege to create users and manage roles. References • sql-reference/sql-statements/account-management/CREATE_USER.md • administration/user_privs/authentication/native_authentication.md • administration/user_privs/authorization/User_privilege.md
r
@Rocky Can these users directly login to starrocks mysql ?
r
Yes, users can directly log in to StarRocks using a standard MySQL client. StarRocks is compatible with the MySQL protocol and, by default, listens for connections from MySQL clients on port 9030. Whether "these" specific users can log in depends on how they are authenticated and authorized within StarRocks. Here are the common scenarios: 1. Native Authentication (Standard Users) If the users were created directly in StarRocks using the 
CREATE USER
command, they can log in using their username and password:
Copy code
bash
mysql -h <fe_ip> -P 9030 -u <username> -p
2. External Authentication (LDAP, JWT, OAuth 2.0) StarRocks supports several external authentication methods. If your users are managed in an external system, they can still log in via the MySQL protocol: * LDAP: Users can log in with their LDAP credentials if StarRocks is integrated with your LDAP/AD server. * JWT (JSON Web Token): Starting from v3.5.0, users can log in using a JWT token with a compatible MySQL client (version 9.2 or later). * OAuth 2.0: Users can connect via a MySQL client; the system will return a URL for the user to complete authentication in a browser before granting access. 3. Users Accessing External Catalogs (Hive, Iceberg, etc.) If you are referring to users who need to access data in an External Catalog: * They must first be able to log in to StarRocks (using one of the methods above). * They must be granted the 
USAGE
permission on the specific Catalog:
Copy code
sql
    GRANT USAGE ON CATALOG <catalog_name> TO USER <username>;
* If you use Apache Ranger for centralized policy management, StarRocks can match the StarRocks user with the Ranger user of the same name to enforce permissions. Summary of Requirements: * Network: Access to the Frontend (FE) IP on the query port (default 
9030
). * Identity: A user identity must exist in StarRocks (either manually created or synced/authenticated via LDAP/OAuth/JWT). * Client: Any standard MySQL client or JDBC/ODBC driver. If you have a specific group of users in mind (e.g., "users from my LDAP group" or "users from a specific cloud IAM role"), let me know, and I can give you the exact configuration steps! References • administration/user_privs/authorization/ranger_plugin.md • integrations/authenticate_to_aws_resources.md • data_source/catalog/catalog_overview.md • data_source/catalog/iceberg/iceberg_rest_security.md
r
@Rocky What is the reason for this error in init-pwd pod: ERROR 1045 (28000): Access denied for user 'root' (using password: NO) error code: 1045 Password error, believed to have been changed, exiting normally
r
The error you are seeing in the 
init-pwd
(or 
kube-starrocks-initpwd
) pod is actually a handled exception and typically indicates that the initial password setup has already been completed. What is happening? The 
init-pwd
pod is a helper job created by the StarRocks Operator or Helm chart. Its sole purpose is to: 1. Connect to the StarRocks FE as the 
root
user with no password (the default state of a new cluster). 2. Execute the 
SET PASSWORD
command to secure the 
root
account with the password provided in your Kubernetes secrets. Why you see this error: When the pod runs, it first tries to log in without a password. If the password has already been set (either by a previous run of this same pod or manually by an administrator), the MySQL client returns: 
ERROR 1045 (28000): Access denied for user 'root' (using password: NO)
The script inside the pod is designed to catch this specific error code. When it sees 
1045
, it logs the message: 
Password error, believed to have been changed, exiting normally
It then exits with a status code of 0 (Success). This prevents the pod from staying in a 
CrashLoopBackOff
state and signals to Kubernetes that the initialization task is "finished" because the password is no longer the default empty string. Is this a problem? * If your cluster is working and you can log in: You can safely ignore this log. The pod has fulfilled its purpose (or confirmed that the purpose was already fulfilled) and will stop. * If you cannot log in to your cluster: This means the password was set to something other than what you expected. Check the Kubernetes secret you used for 
initPassword
to confirm the value, or follow the password recovery procedure if you have lost the password. Summary This log message is a confirmation of success rather than a failure; it means the 
root
user is already protected by a password, and the initialization script doesn't need to do anything further. References • administration/user_privs/authentication/native_authentication.md • faq/Others.md • deployment/post_deployment_setup.md • administration/Meta_recovery.md
r
@Rocky Why getting these errors in CN and other FE(follower) pods:
Copy code
Tue Feb 17 21:20:43 CST 2026] Add myself (kube-starrocks-cn-1.kube-starrocks-cn-search.asd43.svc.cluster.local:9050) into FE ...
ERROR 1045 (28000): Access denied for user 'root' (using password: YES)
ERROR 1045 (28000): Access denied for user 'root' (using password: YES)
This is my helm values:
Copy code
metrics:
  serviceMonitor:
    enabled: true
starrocksCluster:
  namespace: "asd43"
  # specify the BE/CN deployment or not.
  enabledBe: false
  enabledCn: true
  componentValues:
    serviceAccount: kubvir-asd43-starrocks-s3-sa
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: namespace
            operator: In
            values: ["dock"]
          - key: <http://karpenter.sh/capacity-type|karpenter.sh/capacity-type>
            operator: In
            values: [ "on-demand" ]
          - key: <http://kubernetes.io/arch|kubernetes.io/arch>
            operator: In
            values:
            - amd64
          - key: <http://kubernetes.io/os|kubernetes.io/os>
            operator: In
            values:
            - linux
initPassword:
  enabled: true
  passwordSecret: kubvir-asd43-starrocks-root-password
  podAnnotations:
    <http://sidecar.istio.io/inject|sidecar.istio.io/inject>: "false"
# ============================================================
# FE-PROXY — EXPOSE THROUGH ALB (HTTP only)
# ============================================================
starrocksFeProxySpec:
  enabled: true
  service:
    type: ClusterIP
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: namespace
            operator: In
            values: ["dock"]
          - key: <http://karpenter.sh/capacity-type|karpenter.sh/capacity-type>
            operator: In
            values: [ "on-demand" ]
          - key: <http://kubernetes.io/arch|kubernetes.io/arch>
            operator: In
            values:
            - amd64
          - key: <http://kubernetes.io/os|kubernetes.io/os>
            operator: In
            values:
            - linux
# ============================================================
# FE (FrontEnd Service) — EXPOSE THROUGH NLB (MySQL + HTTP)
# ============================================================
starrocksFESpec:
  annotations:
    <http://sidecar.istio.io/inject|sidecar.istio.io/inject>: "false"
  service:
    type: ClusterIP
    ports:
      - name: query
        port: 9030
      - name: http
        port: 8030
  replicas: 3
  resources:
    requests:
      cpu: 3
      memory: 8Gi
    limits:
      cpu: 3
      memory: 8Gi
  config: |
    run_mode = shared_data
    cloud_native_storage_type = S3
    aws_s3_path = kubvir-asd43-starrocks-data/starrocks/
    aws_s3_region = us-east-1
    aws_s3_endpoint = <https://s3.amazonaws.com>
    enable_load_volume_from_conf=true
    aws_s3_use_instance_profile=false
    aws_s3_use_aws_sdk_default_behavior=true
    audit_log_modules = slow_query, query, connection
    audit_log_json_format = true
    qe_slow_log_ms = 1000
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: namespace
            operator: In
            values: ["dock"]
          - key: <http://karpenter.sh/capacity-type|karpenter.sh/capacity-type>
            operator: In
            values: [ "on-demand" ]
          - key: <http://kubernetes.io/arch|kubernetes.io/arch>
            operator: In
            values:
            - amd64
          - key: <http://kubernetes.io/os|kubernetes.io/os>
            operator: In
            values:
            - linux
# ============================================================
# CN (Compute Node)
# ============================================================
starrocksCnSpec:
  annotations:
    <http://sidecar.istio.io/inject|sidecar.istio.io/inject>: "false"
  replicas: 2
  resources:
    requests:
      cpu: 8
      memory: 16Gi
    limits:
      cpu: 8
      memory: 16Gi
  config: |
   datacache_disk_size = 80%
  storageSpec:
    storageClassName: "gp3"
    storageSize: 1Ti
    storageCount: 2
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: namespace
            operator: In
            values: ["dock"]
#          - key: <http://karpenter.sh/capacity-type|karpenter.sh/capacity-type>
#            operator: In
#            values: [ "on-demand" ]
          - key: <http://kubernetes.io/arch|kubernetes.io/arch>
            operator: In
            values:
            - amd64
          - key: <http://kubernetes.io/os|kubernetes.io/os>
            operator: In
            values:
            - linux
r
The error 
ERROR 1045 (28000): Access denied for user 'root' (using password: YES)
during the registration of Compute Nodes (CN) or FE followers indicates that the pods are attempting to join the cluster using a password that the FE Leader is rejecting. Based on your Helm values, here are the likely causes and solutions: 1. Missing FE Persistence (Critical for Shared-Data) In your 
starrocksFESpec
, you have not defined a 
storageSpec
. * The Problem: Without a 
storageSpec
, the StarRocks Operator uses 
emptyDir
for FE metadata. Since you have 
replicas: 3
, each FE pod starts with its own empty metadata. When 
run_mode = shared_data
is used, FE metadata is the source of truth for the cluster state, including the root password. * The Consequence: Because there is no persistent storage, the FEs cannot consistently share or maintain the root password set by the 
initpwd
job. If an FE pod restarts, it loses the password and reverts to an empty one, while the CN pods (configured via 
initPassword
) continue trying to connect with the password from your secret. * The Fix: Add a 
storageSpec
to your 
starrocksFESpec
to ensure metadata persists across restarts and replicas.
Copy code
yaml
starrocksFESpec:
  # ... other config ...
  storageSpec:
    name: fe-meta
    storageClassName: "gp3" # Use your storage class (e.g., gp3)
    storageSize: 10Gi
2. Verify Secret Key Name The StarRocks Operator and the Helm chart scripts specifically look for a key named 
password
 inside the Kubernetes secret. * The Problem: If you created your secret 
kubvir-asd43-starrocks-root-password
with a different key (e.g., 
root-password
or 
token
), the registration script might be retrieving an empty or incorrect value. * The Fix: Ensure the secret was created correctly:
Copy code
bash
    kubectl create secret generic kubvir-asd43-starrocks-root-password \
      --from-literal=password='YOUR_ACTUAL_PASSWORD' \
      -n asd43
You can verify the key name with:
Copy code
bash
    kubectl get secret kubvir-asd43-starrocks-root-password -n asd43 -o jsonpath='{.data}'
3. Check the 
initpwd
Job Status The 
kube-starrocks-initpwd
pod is responsible for connecting to the FE and running the 
SET PASSWORD
command. * The Problem: If this job fails or hasn't finished, the FE still has an empty password, but the CN pods are already trying to use the password from the secret. * The Fix: Check the logs of the 
initpwd
pod:
Copy code
bash
    kubectl logs -l <http://app.kubernetes.io/name=starrocks-initpwd|app.kubernetes.io/name=starrocks-initpwd> -n asd43
Note: It is normal for this pod to show 
CrashLoopBackOff
temporarily while waiting for the FEs to become ready. 4. Existing Cluster Password Mismatch If you previously deployed this cluster and later enabled 
initPassword
or changed the secret: * The Problem: The 
initPassword
job only runs successfully once when it detects an empty password. If the FE already has a password set (from a previous install with persistent volumes, though not applicable here due to your current config), the job cannot change it, but the CNs will start using the new secret value. * The Fix: Since you are currently using 
emptyDir
(no persistence), the easiest way to "reset" is to delete the FE pods/StatefulSet so they start fresh once you've added the 
storageSpec
. Summary of Recommended Changes Update your 
starrocksFESpec
to include persistence:
Copy code
yaml
starrocksFESpec:
  replicas: 3
  storageSpec: # Add this section
    name: fe-meta
    storageClassName: "gp3"
    storageSize: 10Gi
  config: |
    run_mode = shared_data
    # ... rest of your config ...
After applying this, the FEs will have a consistent place to store the cluster state and root password, allowing the CNs and followers to authenticate successfully. References • quick_start/helm.md
r
@Rocky I have storageSpec defined in other values yaml of helm chart and override only other values what I shared earlier:
Copy code
storageSpec:
    # Specifies the name prefix of the volumes to mount. If left unspecified,
    # `emptyDir` volumes will be used by default, which are ephemeral and data
    # will be lost on pod restart.
    #
    # For persistent storage, specify a volume name prefix.
    # For example, using `fe` as the name prefix would be appropriate.
    # Note: If the values of the following mountPaths are not default, you must set the name to fe.
    name: "fe"
    # The storageClassName represent the used storageclass name. If not set will use k8s cluster default storageclass.
    # You must set a name when you set storageClassName.
    # Note: Because hostPath field is not supported here, hostPath is not allowed to be set in storageClassName.
    storageClassName: ""
    # the persistent volume size for data.
    # FE container stops running if the disk-free space which the FE meta-directory residents is less than 5Gi.
    storageSize: 10Gi
    # If storageMountPath is empty, the storageMountPath will be set to /opt/starrocks/fe/meta.
    storageMountPath: "/opt/starrocks/fe/meta"
    # If not set will use the value of the storageClassName field.
    logStorageClassName: ""
    # Setting this parameter can persist log storage, and the mount path is /opt/starrocks/fe/log.
    # If you set it to 0Gi, the related PVC will not be created, and the log will not be persisted.
    logStorageSize: 5Gi
    # If logMountPath is empty, the logMountPath will be set to /opt/starrocks/fe/log.
    # If logMountPath is not /opt/starrocks/fe/log, you must add in config the following configuration:
    #    dump_log_dir = xxx
    #    sys_log_dir = xxx
    #    audit_log_dir = xxx
    logMountPath: "/opt/starrocks/fe/log"
r
That configuration looks correct for setting up persistent storage for your StarRocks FE nodes using the Helm chart (typically via the StarRocks Operator). Here are a few key points regarding the 
storageSpec
you've defined: *1. Persistent Storage Activation* By setting 
name: "fe"
, you are explicitly enabling Persistent Volume Claims (PVCs) for the FE. If this were left as 
""
, the chart would default to 
emptyDir
, and you would lose all metadata and logs upon Pod restart. *2. Storage Sizes* * Metadata (
storageSize: 10Gi
): This is a safe choice. StarRocks FE will stop running if the free disk space for the metadata directory falls below 5Gi, so 10Gi provides a healthy buffer for typical metadata growth. * Logs (
logStorageSize: 5Gi
): This is sufficient for standard logging. If you expect high audit log volume, you might need to monitor this or adjust log rotation. *3. Mount Paths & Config Requirements* Your configuration uses the default paths: * 
storageMountPath: "/opt/starrocks/fe/meta"
* 
logMountPath: "/opt/starrocks/fe/log"
Crucial Note: Since you are using the default 
/opt/starrocks/fe/log
path, you do not need to manually set the log directories in the FE configuration. However, if you ever change 
logMountPath
to something else, you must update the FE configuration (
fe.conf
via 
config
in your YAML) to match:
Copy code
yaml
config: |
  dump_log_dir = /your/custom/path/dump
  sys_log_dir = /your/custom/path/sys
  audit_log_dir = /your/custom/path/audit
*4. Storage Class* * 
storageClassName: ""
will tell Kubernetes to use the default StorageClass defined in your cluster. Ensure your cluster has a default StorageClass (you can check with 
kubectl get sc
). *5. Naming* The 
name: "fe"
serves as a prefix for the volumes. For FE 0, this will result in PVC names like: * 
fe-meta-kube-starrocks-fe-0
* 
fe-log-kube-starrocks-fe-0
Recommendation: If you are deploying in a production environment, ensure your StorageClass supports 
volumeBindingMode: WaitForFirstConsumer
(common in cloud providers) to ensure the PV is created in the same availability zone as the Pod. Does this match what you were intending to implement, or are you seeing any specific errors when applying this? References • quick_start/helm.md • sql-reference/sql-statements/cluster-management/storage_volume/CREATE_STORAGE_VOLUME.md • deployment/shared_data/s3.md
r
@Rocky Why these errors in initpwd pod:
Copy code
kubectl logs -l job-name=kube-starrocks-initpwd -n devtest03
ERROR 1045 (28000): Access denied for user 'root' (using password: NO)
error code: 1045
Password error, believed to have been changed, exiting normally
r
The error you are seeing in the 
kube-starrocks-initpwd
pod logs is a common behavior during the initialization or update process of a StarRocks cluster managed by the StarRocks Operator. Why this happens The 
kube-starrocks-initpwd
job is designed to automate the setting of the 
root
user password. Its logic typically follows these steps: 1. Attempt Connection: It tries to connect to the StarRocks FE (Front End) using the username 
root
and no password (the default state of a new cluster). 2. Access Denied (The Error): If the password has already been set (either by a previous run of this job or manually by an administrator), the connection fails with: 
ERROR 1045 (28000): Access denied for user 'root' (using password: NO)
. 3. Heuristic Exit: The script detects this specific error (1045) and assumes that since it cannot log in with an empty password, the password must have already been configured. 4. Exiting Normally: It prints 
Password error, believed to have been changed, exiting normally
and exits with a success code (0) so the Kubernetes Job can move to a 
Completed
state. Is this a problem? * If the pod status is `Completed`: You can ignore these log messages. It means your StarRocks cluster already has a root password set, and the initialization job is gracefully standing down. * If you are trying to change an existing password: The 
initpwd
job cannot change a password that is already set. It only handles the transition from no password to the password defined in your Kubernetes secret. What to do next 1. Verify Login: Try connecting to your StarRocks cluster manually using the password defined in your secret:
Copy code
bash
    mysql -h <fe_ip> -P9030 -uroot -p'YOUR_PASSWORD'
2. Manually Update Password: If you need to change the password and the cluster is already initialized, you must do it via SQL:
Copy code
sql
    SET PASSWORD FOR 'root' = PASSWORD('new_password');
3. Check Pod Status: Run 
kubectl get pods -n devtest03
and look for 
kube-starrocks-initpwd
. If it is in the 
Completed
state, the operator considers the task finished. Note: It is normal for this pod to go through 
Error
or 
CrashLoopBackOff
states initially while waiting for the FE nodes to become ready and accept connections. Only if it stays in a failing state indefinitely (without the "exiting normally" message) is there a deeper configuration issue. References • quick_start/helm.md • deployment/post_deployment_setup.md • administration/user_privs/authentication/native_authentication.md • deployment/helm.md
r
@Rocky When I enter root user password, it gives access denied
r
It sounds like you're encountering an authentication issue with the 
root
user. This typically happens for one of two reasons: either the default password isn't what you expect, or the root password was previously changed and lost. Here is how you can resolve this: 1. Try the Default Password When a StarRocks cluster is first created, the 
root
user has no password (it is empty). * Try connecting without the 
-p
flag:
Copy code
bash
    mysql -h <fe_ip> -P9030 -uroot
* If you are prompted for a password, simply press Enter without typing anything. 2. Reset the Root Password (If lost) If you have already set a password and forgotten it, you can reset it by temporarily disabling authentication: 1. Disable Auth Check: Edit the 
fe/conf/fe.conf
file on all FE nodes and add/change this line:
Copy code
yaml
    enable_auth_check = false
2. Restart FE: Restart all FE nodes to apply the change:
Copy code
bash
    ./fe/bin/stop_fe.sh
    ./fe/bin/start_fe.sh
3. Log in without password: Connect using the MySQL client (it will not check for a password now):
Copy code
bash
    mysql -h <fe_ip> -P9030 -uroot
4. Reset Password: Run the following SQL command to set a new password:
Copy code
sql
    SET PASSWORD FOR 'root' = PASSWORD('your_new_password');
5. Re-enable Auth Check: Change 
enable_auth_check
back to 
true
in 
fe.conf
and restart all FE nodes again. 3. Check Host Permissions If you see an error like 
Access denied for user 'root'@'192.168.1.10'
, it might be because the 
root
user is restricted to specific hosts. However, by default, the StarRocks 
root
user is created as 
root@'%'
(allowing access from any host). If this was changed, you would need to use the "Reset Root Password" method above to log in and then fix the user permissions with 
CREATE USER
or 
GRANT
. Note: Always ensure you are connecting to the correct Query Port (default is 
9030
), not the Edit Log Port or HTTP Port. References • administration/user_privs/authentication/native_authentication.md • deployment/post_deployment_setup.md • quick_start/helm.md • deployment/deploy_manually.md
3 Views
Open in Slack
PreviousNext
Powered by