This article focuses on troubleshooting the “Operation not permitted” error during KingbaseES installation on NFS shared storage. The core challenge is that what looks like a simple permission issue often masks missing environment variables, improper mount options, and blocked security policies. Keywords: KingbaseES, NFS, environment variables.
The technical specification snapshot clarifies the deployment context
| Parameter | Description |
|---|---|
| Target software | KingbaseES V9 |
| Operating system | Linux |
| Shell | Bash |
| Storage protocol | NFS |
| Typical error | ./setup: Operation not permitted |
| Core dependencies | glibc, mount, nfsstat, ausearch |
| Key configuration | PATH, LD_LIBRARY_PATH, KINGBASE_HOME |
| Primary risk factors | noexec, root_squash, SELinux, user switching method |
This error usually indicates a broken execution path rather than a single permission failure
When you deploy KingbaseES in an NFS environment, Operation not permitted is easy to misdiagnose as a standard file permission problem. In real-world cases, it is often caused by multiple conditions at once: an incomplete user environment, NFS mount restrictions, security module enforcement, or mismatched directory ownership.
A more subtle issue is that the installer depends on variables such as PATH, HOME, and LD_LIBRARY_PATH to locate binaries and shared libraries. If you switch users incorrectly and the shell does not load initialization files, the program may execute from the wrong path and ultimately fail with an apparent execution error.
Minimal reproduction can expose the failure path quickly
# Mount the shared NFS directory
mount -t nfs 192.168.1.100:/data /data
# Switch to the database installation user
su - kingbase
# Enter the installation directory and run the installer
cd /data/kingbase
./setup # If this returns Operation not permitted, continue by checking the environment and mount optionsThis command sequence reproduces a typical execution failure during installation in an NFS-based environment.
The issue is usually triggered by four root cause categories
Environment variables may not be loaded correctly
If you use su kingbase instead of su - kingbase, or if you start a non-login shell immediately after SSH login, .bash_profile and .bashrc may not be loaded. In that case, the database command path, library path, and data directory variables may all be empty.
NFS mount options may directly block file execution
If the mount options include noexec, executables on the mount point cannot run. If they include nosuid, workflows that depend on privilege bits may also fail. These issues are especially common in shared storage environments.
Server-side identity mapping affects client-side permissions
By default, NFS root_squash maps remote root to an anonymous user. Even if the client appears to execute commands with elevated privileges, the server may still reject critical write or execution operations. That is why the system can look properly privileged while still refusing to execute.
# Return to the user home directory and reload environment variables
cd /home/kingbase
source ~/.bashrc # Reload the environment variables required by the database
echo "$KINGBASE_HOME"
echo "$LD_LIBRARY_PATH"This command sequence verifies whether environment variables are missing and provides the fastest recovery method.
Pre-install validation should become a standard procedure
Instead of troubleshooting after failure, run a minimal self-check before installation. Focus on the user identity, directory ownership, library dependencies, resource limits, and NFS parameters. This can significantly reduce misdiagnosis.
User identity and directory permissions must align first
whoami # Confirm the current execution user
id kingbase # Check the database user UID and GID
ls -ld /data/Kingbase/ES/V9 # Confirm the ownership and permissions of the installation directoryThis set of commands confirms the execution identity, group membership, and whether the installation directory belongs to the correct user.
Use a dedicated database account for deployment instead of installing directly as root. In most cases, directory permissions should remain at 750 or 755, and the owner should match the runtime user.
Environment variables should be explicitly configured instead of relying on memory
export KINGBASE_HOME=/data/Kingbase/ES/V9 # Define the database installation root directory
export PATH=$KINGBASE_HOME/bin:$PATH # Add the executable command path
export LD_LIBRARY_PATH=$KINGBASE_HOME/lib:$LD_LIBRARY_PATH # Add the shared library search path
export KINGBASE_DATA=$KINGBASE_HOME/data # Define the data directoryThis configuration provides the core environment variables required for KingbaseES installation and runtime.
System dependencies and resource limits determine installation stability
Check the glibc version, file descriptor limits, and shared memory capabilities first. A successful installation does not guarantee stable runtime behavior. Many issues surface during initialization or the first startup.
ldd --version | head -1 # Confirm whether the glibc version meets the requirement
ulimit -n # Check the file descriptor limit
ipcs -l # View shared memory and IPC limitsThese commands provide a quick pre-install assessment of the system’s baseline runtime readiness.
NFS mount settings must be optimized for database workloads
Databases require strong consistency, recoverability, and stable I/O behavior. Default NFS mount options are often not safe enough. Execution permissions and attribute caching deserve particular attention.
Recommended mount options should avoid execution restrictions while preserving consistency
mount -t nfs -o rw,bg,hard,nointr,noac,rsize=32768,wsize=32768,tcp,noatime,actimeo=0 \
192.168.1.100:/data /data # Explicitly specify NFS mount options suitable for database workloadsThis command provides a more stable NFS mount baseline for database-style workloads.
hard ensures that requests hang during service interruption instead of failing silently. tcp improves transport reliability. actimeo=0 helps reduce the risk of state inconsistency caused by attribute caching. Most importantly, make sure the mount does not include noexec.
Server export policies also affect the outcome
cat /etc/exports
# /data 192.168.1.0/24(rw,sync,no_subtree_check,anonuid=1001,anongid=1001)This configuration maps anonymous access on the server side to the database account, which helps reduce permission mismatches caused by root_squash.
If you must support specific elevated-privilege scenarios, you can evaluate no_root_squash. However, in production environments, a controlled UID/GID mapping strategy is usually the safer choice.
Shell debugging should narrow the problem in a fixed sequence
When this error occurs, do not modify permissions immediately. Instead, investigate in this order: identity, environment, files, mount settings, security policies, and logs. This approach reduces the root cause much faster.
A one-click diagnostic script can replace repetitive manual checks
#!/bin/bash
# Quick diagnostic for the KingbaseES NFS deployment environment
echo "== User Check =="
whoami
id
echo "== Environment Variable Check =="
echo "$KINGBASE_HOME"
echo "$LD_LIBRARY_PATH"
echo "$PATH" | grep -i kingbase
echo "== NFS Mount Check =="
mount | grep nfs # Confirm whether risky options such as noexec or nosuid are present
echo "== Execution Capability Test =="
cp /bin/ls /data/test_exec && /data/test_exec && rm -f /data/test_execThis script validates the user identity, environment variables, NFS mount status, and execution capability on the mount point in a single pass.
Logs and security modules often provide the final evidence
If environment variables and mount options look correct, continue by checking SELinux or AppArmor. For SELinux, confirm the current mode first, then inspect the audit logs for AVC denials.
getenforce # Confirm the current SELinux mode
dmesg | grep -i nfs # View kernel-level NFS exceptions
ausearch -m avc | tail -20 # Check SELinux denial logsThese commands help confirm whether a security policy or kernel-level event is blocking execution.
The final conclusion should be codified into deployment standards
The most valuable lesson from this class of issue is simple: do not treat Operation not permitted as a synonym for “just run chmod.” In KingbaseES deployments on NFS, the most common root cause is an unloaded shell environment, followed by mount options and identity mapping.
Write the following actions into your standard SOP: always use su - kingbase, run the pre-install self-check script, configure environment variables explicitly, forbid noexec in mount options, and retain logs plus configuration change records after deployment. This is far more reliable than post-incident firefighting.
FAQ provides structured answers to the most common questions
Q1: Why does ./setup still return Operation not permitted even when directory permissions look correct?
A: The most common cause is not directory permissions. It is usually either an NFS mount that includes noexec, or a user switch that failed to load .bashrc or .bash_profile, which prevents the installer from locating required dependency paths.
Q2: Why does the difference between su kingbase and su - kingbase affect installation?
A: su - starts a login shell and loads the target user’s environment configuration. Without -, the command often switches identity without switching the environment, which leaves PATH, LD_LIBRARY_PATH, and KINGBASE_HOME undefined.
Q3: Is NFS suitable for directly hosting KingbaseES data files?
A: That depends on the deployment model. In standalone or primary-standby scenarios, local disks are usually better for core data, while NFS is more suitable for archives or shared configuration. For truly high-consistency shared storage scenarios, dedicated solutions such as SAN are typically a better fit.
AI Readability Summary
This article reconstructs a practical troubleshooting path for the “Operation not permitted” error that appears when deploying KingbaseES on NFS shared storage. It focuses on four common root causes: unloaded environment variables, NFS noexec or root_squash, SELinux enforcement, and directory permission mismatches. It also provides pre-install validation steps, recommended mount options, shell debugging methods, and a reusable diagnostic script.