Skip to main content
Sign in

TuxCare Knowledge Base

  1. TuxCare
  2. KernelCare
  3. Articles

kcarectl --update returns HTTP Error 401: Unauthorized while the KernelCare license is valid

Pavel Razumov
  • Updated

Issue

Running kcarectl --update fails to download live patches and returns HTTP Error 401: Unauthorized, even though the KernelCare license is valid and the server is registered in CloudLinux Network (CLN):

[root@server ~]# kcarectl --update
Downloading updates
Unable to access server. Retrying...
HTTP Error 401: Unauthorized: https://patches.kernelcare.com/patches/K20260822_0002/<kernel-hash>/<patch-level>/kpatch.bin

Only the patch file itself is refused. The agent reaches the patch server and receives the patch metadata normally: latest.v3 returns the current patch level for the kernel, and release.content.json is written to /var/cache/kcare/patches/. The refusal happens at the kpatch.bin download.

The license is reported as valid on the server:

[root@server ~]# kcarectl --license-info
Key-based valid license found

Deleting and re-adding the license in CLN, re-registering the agent, and re-running the KernelCare installer do not restore access.

You may also see the following alongside this error. None of them is a separate fault, and none needs action on the server:

  • kcarectl --update returning exit code 0 even though the download failed
  • kcarectl --status returning exit code 1, and /proc/kcare/effective_version and /proc/kcare/cvelist being absent — expected while no patch is applied
  • The diagnostic report upload failing with HTTP 401 - 401 Authorization Required, after which the agent falls back to the legacy flow and still prints a usable doctor key
  • On servers with a non-English system locale, prepare_doctor_report() failed: 'latin-1' codec can't encode character ..., again followed by the legacy flow completing successfully

Environment

  • KernelCare, KernelCare Enterprise, KernelCare+ (including KernelCare enabled through Imunify360)
  • KernelCare Agent (kcarectl), any version — confirmed on 3.8-1
  • Key-based and IP-based licenses
  • Any operating system supported by KernelCare — confirmed on AlmaLinux 9, CloudLinux OS 9 and Debian 12 (the failure is server-side and is not distribution-specific)
  • Most often on servers registered recently

Solution

  1. Confirm the license itself is valid:
   kcarectl --license-info

A working license reports Key-based valid license found, or Valid license found for IP <address> on an IP-based license. If it reports No valid key-based license found or an expired trial instead, this article does not apply — follow KernelCare responses with the "HTTP Error 401: Unauthorized" error during update.

  1. Confirm in CLN that the server is registered.
  2. If KernelCare is enabled through Imunify360, do not run kcarectl --register with the Imunify360 key. That key is not a KernelCare registration key, and Invalid Key is the expected answer. KernelCare+ is licensed through the Imunify360 registration itself, so /etc/sysconfig/kcare/systemid is not created on these servers and its absence is not a fault.
  3. Do not remove and re-add the license, re-register, or re-run the installer. None of these clears the error, and a new registration issues a new server ID that has to be authorised again, which restarts the wait.
  4. Wait a few minutes and run the update again:
   kcarectl --update

The entitlement data that the patch server checks is synchronised from CLN. A 401 raised during a short synchronisation gap clears on its own once the record arrives, with no change on the server.

  1. If the 401 is still returned after several attempts over more than 30 minutes, including the automatic runs, open a support ticket and include:

    • the full kcarectl --update output, with the complete patch URL (kernel hash and patch level unmasked)
    • the output of kcarectl --license-info
    • the IP address of the affected server
    • the key printed by kcarectl --doctor

    If the doctor report upload returns 401 Authorization Required, let the command finish: the agent falls back to the legacy flow, completes the upload and prints the key. Send that key.

  2. Leave automatic updates enabled (AUTO_UPDATE=True in /etc/sysconfig/kcare/kcare.conf). No recovery procedure is needed on the server. Once the authorisation is corrected, the next scheduled run downloads and applies the patch without any command from you.

Cause

The failure is raised by the authorisation layer in front of patches.kernelcare.com, which checks every patch download against the entitlement record it receives from CLN. kcarectl --license-info reports only the registration stored on the server, so a correctly registered server is still refused while that entitlement record is not in place. Neither the license, nor the kernel, nor the patch release is at fault: in the reported cases the requested release was published and unblocked for all channels, the account was within its license quota, and the same key was in use on working servers.

Two situations produce this:

  • A short synchronisation gap after registration. The entitlement record has not yet reached the patch server. It clears on its own within minutes, and the same request then returns HTTP 200 with no change made on the server. Tracked as PF-2622 (resolved).
  • Newly registered servers refused for hours. From 26/08/26, servers registered that day were refused at the patch payload while the metadata requests were served normally, and the error did not clear on retry over several hours. This was reproduced on a freshly registered internal test server on a different account, a different operating system and a different license type, so it is not limited to one account, key or platform. This is an open defect on the TuxCare side, tracked as PF-2957; this article will be updated when the fix is confirmed.

Useful Links

Comments

0 comments

Article is closed for comments.