Werk #22168: mk-job: Fix job folder access in single-directory deployment
| Component | Agent bakery | ||||
| Title | mk-job: Fix job folder access in single-directory deployment | ||||
| Date | Oct 21, 2026 | ||||
| Level | Trivial Change | ||||
| Class | Bug Fix | ||||
| Compatibility | Incompatible - Manual interaction might be required | ||||
| Checkmk versions & editions |
|
With the single-directory deployment (Werk #17900), users that run mk-job couldn't reach their job folder runtime/job/<user>. The folders runtime and runtime/job below the agent installation directory had the mode 750. As a result, mk-job exited with an error and didn't run the job at all.
The workaround was chmod o+x on both folders. On RPM-based systems, every agent update reset the mode to 750 again.
Both folders now have the mode 751. Other users can traverse them to reach their job folder, but they can't list their contents. As before, an administrator has to create runtime/job/<user> for each user that runs mk-job, owned by that user.
The agent's data below runtime stays closed for other users. The agent and its plug-ins create the folders cache, logwatch-batches, persisted, rtc_remotes and tmp on demand, and these folders used to be readable for others. They hold, for example, the output of cached plug-ins and matched log lines. The package now ships them with the mode 750. On RPM-based systems, the agent update applies the new modes to existing folders as well.
On DEB-based systems, an agent update never changes the mode of an existing folder. There, only new installations get the new modes. On an existing DEB host, runtime and runtime/job keep the mode 750. Without the workaround, mk-job keeps failing there. If you use mk-job on an existing DEB host, or have applied the workaround there, run the following command once. With the default installation directory, it is:
cd /opt/checkmk/agent/default/runtime && chmod 751 . job && chmod 750 cache logwatch-batches persisted rtc_remotes tmp
The second chmod reports an error for each folder that doesn't exist on the host. You can ignore these errors.
Non-root deployment
In the non-root deployment (Werk #17901), every agent installation and update gave the whole runtime folder to the agent user. This included the job folders below runtime/job, so mk-job lost write access after each agent update. The installation now leaves these job folders to their users.
If an earlier update has already changed the owner of a job folder, give it back to its user once. With the default installation directory, the command is:
chown -R <user> /opt/checkmk/agent/default/runtime/job/<user>