> Source: [sk180562](https://support.checkpoint.com/results/sk/sk180562) # sk180562 - Error "CLINFR0819 User: denied access via CLI" when running several clish commands in a REST API session | Property | Value | |----------|-------| | Solution ID | sk180562 | | Date Created | 2023-01-30 | | Last Modified | 2025-02-18 | | Technical Level | General | | Products | Security Gateway, Security Management Server, Multi-Domain Security Management Server | | Versions | R82, R81.20, R81.10 (EOS), R82, R81.20, R81 (EOS), R81.10 (EOS), R81 (EOS), R81 (EOS), R81.10 (EOS), R81.20, R82 | | OS | Gaia | ## Solution (1) Error "CLINFR0819 User: \ denied access via CLI" when running several clish commands in a REST API session ------------------------------------------------------------------------------------------------------------------------- **Additional Symptoms:** * The issue may occur with different API implementations (for example: ansible, python SDK, and so on). * The user who executes the commands is a remote user (RADIUS / TACACS) with a `clish `default shell. * The commands are executed with a "`clish -c`" flag. Show / Hide solution **Cause:** When using the "`clish -c`" flag, each time a new command is executed, the Security Gateway creates a new `clish `session. The `clish `session details are currently not preserved for 3rd party authorization (remote users), and it prevents the rest of the "`clish -c`" commands from executing properly. **Solution:** To run multiple "`clish -c"` commands from a single API / ansible / python implementation: 1. Add them to a text file. 2. Execute at once from the the text file with "`clish -f`" flag. Sample extract from a non-working python script: `for helper in ip_helper:` ` script = f'''{script}` `/bin/clish -c "set bootp interface {interface_name} relay-to {helper} on"'''` `script = f'''{script}` `/bin/clish -c "set bootp interface {interface_name} primary {primary_address}"` `/bin/clish -c "set bootp interface {interface_name} wait-time 0"` `/bin/clish -c "set bootp interface {interface_name} maxhopcount 8"` `/bin/clish -c "save config"` `/bin/clish -c "unlock database"` Sample extract from a working python script: `for helper in ip_helper:` ` script = f'''{script}` `echo "set bootp interface {interface_name} relay-to {helper} on" >> test.txt'''` `script = f'''{script}` `echo "set bootp interface {interface_name} primary {primary_address}" >> test.txt` `echo "set bootp interface {interface_name} wait-time 0" >> test.txt` `echo "set bootp interface {interface_name} maxhopcount 8" >> test.txt` `echo "save config" >> test.txt` `echo "unlock database" >> test.txt` **/bin/clish -f test.txt** (2) "CLINFR0819 User: denied access via CLI" error message during login through CLI ----------------------------------------------------------------------------------- **Additional Symptoms:** * The `/var/log/messages` file shows: snmpd: Error: Couldn't connect to /tmp/xgets: No such file or directory clish[10003]: is_vsx_enabled: libdb error Couldn't connect to /tmp/xgets: No such file or directory monitord[20313]: Error: Couldn't connect to /tmp/xgets: No such file or directory Show / Hide solution **Solution:** Note that as per [**sk97638** - *Check Point Processes and Daemons*](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk97638), a maintenance window is required when restarting this child daemon. 1. Stop the `confd `process: `[Expert@HostName]# tellpm process:confd` 2. Backup the current Gaia Database: `[Expert@HostName]# mkdir /config/db/BKP` `[Expert@HostName]# mv /config/db/initial_db /config/db/BKP/` 3. Recreate the Gaia Database based on the current configuration: `[Expert@HostName]# conv2db /config/db/initial /config/db/initial_db` 4. Verify that the Gaia Database was recreated: `[Expert@HostName]# ls -l /config/db/initial_db` 5. Assign the required permissions and ownership for the recreated Gaia OS SQL database: `[Expert@HostName]# chown -v admin:root /config/db/initial_db` `[Expert@HostName]# chmod -v u=rw,g=r,o=r /config/db/initial_db` `[Expert@HostName]# ls -l /config/db/initial_db` 6. Set the revisions time in the Gaia Database: `[Expert@HostName]# sqlite3 /config/db/initial_db "update revisions set time='1980-01-01 02:00:00';"` 7. Reboot the device: `[Expert@HostName]# reboot`
**Important Notes**: * Routed daemons are restarted at this point. * Users with expert shell are able to login through the CLI and do not receive the error message. (3) Users with default shell of /etc/cli.sh, are not able to login to the Gaia OS through SSH or console and receive this error: "CLINFR0819 User: admin denied access via CLI" --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **Additional Symptoms:** * "`NMSUSR0026 Couldn't connect to /tmp/xsets: No such file or directory`" error when running the `clish` '`set`' commands. * "`NMSUSR0026 Couldn't connect to /tmp/xgets: No such file or directory`" error when running the `clish` '`show`' commands. * Users with default shell of `/bin/bash` are able to log in normally to the Gaia OS. Show / Hide solution **Cause:** The `/tmp/xgets, /tmp/xsets/` and `/tmp/xdumps` files are missing from the Gaia machine. **Notes:** * Exact root cause of this issue was not determined yet. All reported cases were reported after a single occurrence of this issue, which did not occur again. Therefore, Check Point was not able to investigate this issue properly. * This issue is not related to traffic, and has no impact on traffic. * It is possible someone deleted files from the `/tmp` directory manually while in Expert mode.
**Solution:** Follow these steps: 1. If Expert access is available, manually restart the *confd*` `process: `[Expert@HostName]# tellpm process:confd ; sleep 1 ; tellpm process:confd t`**A maintenance window is required:** * * When the *confd*` `daemon is starting, by design, it restarts any currently running *routed* daemons (by sending a TERM signal). It is done to avoid possible issues in Gaia Clish (for example: returning invalid results for routing-related commands like "`show route`"). * Because the *routed* daemon is responsible for all the routing in the Gaia OS, short traffic outage occurs while the *routed* daemon is restarted. * Because the *routed* daemon is a Critical Device in the Check Point cluster (since R76), cluster fail-over might occur while the *routed* daemon restarts (refer to [sk92878](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk92878)). If Expert access is *not* available, reboot the the Gaia machine to resolve the issue. Another option to resolve this issue: 1. Connect to the Gaia Portal. 2. Change the default shell for all users to */bin/bash*: * In the WebUI, go to**User Management** \> **Users**tab. * Select and edit the relevant user. * Change the **shell** parameter from the default option */etc/cli.sh* to */bin/bash* * Save and exit 3. Change the default shell for all users back to */etc/cli.sh*. A simple reboot of the Security Gateway or the Security Management Server re-populates the `/tmp `directory and the user is able to log back in to the device. (4) Login to Gaia OS Clish fails with "CLINFR0819 User: admin denied access via CLI" after clean installation ------------------------------------------------------------------------------------------------------------- Show / Hide solution **Cause:** In the output of the '`dmidecode`' command, the value of '`Product Name`' is empty (under '`System Information`'): ``` [Expert@HostName]# dmidecode | grep -A2 "System Information" System Information Manufacturer: Product Name: ``` As a result, these files are removed from the device, rendering CLISH unavailable: * `/bin/ipsctl` * `/usr/lib/libipsctl_lib.so` Missing "`Product Name`" is expected only on Open Servers, which meet one (or more) of these conditions: 1. The hardware is *not* listed in the Check Point [Hardware Compatibility List](https://www.checkpoint.com/support-services/hcl/#os) (was not certified). 2. The hardware was customized for the user's needs and it is based on a supported model listed in the [Hardware Compatibility List](https://www.checkpoint.com/support-services/hcl/#os). ****Solution:**** This problem was fixed. The fix is included in: * **[Check Point R77.30](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk104859&js_peid=P-14d3e6d9e20-10001&partition=General&product=All%22)** Check Point recommends to always upgrade to the most recent version ([upgrade Security Gateway](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doShowproductpage&productTab=downloads&product=73) / [upgrade Security Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doShowproductpage&productTab=downloads&product=184) / [upgrade Multi-Domain Security Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doShowproductpage&productTab=downloads&product=166)). If you do not wish to upgrade, follow these steps: 1. If the hardware is ***not*** listed in the Check Point [Hardware Compatibility List](https://www.checkpoint.com/support-services/hcl/), contact Check Point local office and ask to add it to the Hardware Compatibility List. 2. If the hardware was customized for the user's needs **and** it is based on a supported model listed in the [Hardware Compatibility List](https://www.checkpoint.com/support-services/hcl/), [contact Check Point Support](http://www.checkpoint.com/services/contact/index.html) to get a modified ISO for a clean installation. (5) Error "CLINFR0819 User: \ denied access via CLI" is received when running several clish commands in REST API session ----------------------------------------------------------------------------------------------------------------------------------- **Additional Symptoms:** * Multiple messages related to "`/tmp/xgets`" socket during bootup and when running Check Point commands. For example: `Couldn't connect to /tmp/xgets: No such file or directory` * Resetting the `clish `database does not resolve the issue or create the socket. When starting the `confd `process, these error messages appear in connection with loading the security bindings: `xpand[10979]: loadDataFromXml: could not read the correct XML path.` `xpand[10979]: Failed to load security forbidden bindings` `pm[3636]: Reaped: confd[10979]` `pm[3636]: Scheduled confd for +256 secs` `monitord[3660]: [149] libdb_get_one error: rc = 1, err = Couldn't connect to /tmp/xgets: No such file or directory` * The Gaia portal does not open with a blank page, although telnet on its `tcp/443` port is successful. * When running the `clish `command, similar output might appear: `[Expert@HostName:0]# clish /etc/features.xml:4801: parser error : Premature end of data in tag DisplayName line 4801 Appliance Mainten ^ /etc/features.xml:4801: parser error : Premature end of data in tag Feature line 4799 Appliance Mainten ^ /etc/features.xml:4801: parser error : Premature end of data in tag Features line 8 Appliance Mainten ^ CLINFR0829 Unable to initiate RBA communication. CLINFR0599 Failed to build ACLs`. In the `/var/log/messages` file, you might see: `clish[25549]: [mrma_init(2645)]: Instance XML doc could not be generated clish[25549]: User admin finished running clish -c due to an error from CLI shell cpviewd: Destroying the lists of sensors`. Show / Hide solution **Cause:** Corruption or incorrect entries in the `/etc/features.xml` file. **Solution:** In comparing the `/etc/features.xml` file on a problematic device with a working one on the same version, there are differences in commands such as "`wc`". To resolve the issue, replace the file as follows: **Note -** Complete these steps during a maintenance window, because restarting `confd `restarts routed as well, which can cause a potential outage and a failover. 1. Create a backup of the current file - `mv /etc/features.xml /etc/features.xml.bkp` 2. Move the new file from a working device to this device - `cp features.xml_good /etc/features.xml` `chmod 644 /etc/features.xml` 3. Restart the `confd` process: `tellpm process:confd` `tellpm process:confd t` Reattempt to log in to clish, it should now work. (6) Error "CLINFR0819 User: \ denied access via CLISH, can't transfer /etc/features.xml from another machine. ------------------------------------------------------------------------------------------------------------------------
Show / Hide solution **Cause:** Corruption or incorrect entries in the /etc/features.xml file. **Solution:** In comparing the /etc/features.xml file on a problematic device with a working one on the same version, there are differences in commands such as "wc". To resolve the issue, replace the file as follows: Replace /etc/features.xml with one of the file below from the machine. `/etc/features.xml` `/etc/features.xml.orig` `/tmp/features-platform.xml` `/tmp/features-trigger.xml` `/etc/features_cpy.xml.api` `cp /etc/features.xml` `chmod 644 /etc/features.xml` Restart the confd process: `tellpm process:confd` `tellpm process:confd t` --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content