using read_only_root_filesystem

[Paul Charran]

I have set the read_only_root_filesystem: True. This, of course, is causing havoc with logs and other files that Wazuh needs to write to. I have found help on the internet recommending mounting rw (Read/Write) directories for Wazuh to use. The problem is if I use the actual directory names as volumes in my properties.yaml, the directory is empty. It can be written to but the other files that were there have been deleted. 

I am proposing creating volumes with alternate names. My question is how to I re-route files like logs and conf files to these volumes? Do I need to hard code in the new rw volumes or is there some other method I am missing?

[Jorge Ardila]

Hi Paul.

I'm currently consulting with our internal team to ensure we provide you with the most accurate and appropriate solution for your scenario. I will get back to you as soon as I have an update.  

Thanks

[Jorge Ardila]

Hi Paul.

Regarding to your question and after investigate about it, using alternate directory names to move Wazuh files is not recommended. Wazuh paths are used internally, and changing them could break functionality or upgrades. 

Mounting a volume over an existing directory (like /var/ossec/logs) hides the original files. They are not deleted, just masked, so the directory looks empty but is writable. 

The best approach is to keep the default structure and mount only the subdirectories that need write access.   

Best regards.

[Paul Charran]

Jorge,

   Thank you for looking into this. I didn't know that Mounting a new volume only hid the original. Is there a way to preserve the original files / directory structure. Maybe copy/paste with a service? If I can find the original that is.

Sincerely,

  Paul

[Jorge Ardila]

Hi Paul.

Could you share the pod configuration you are using to replicate the scenario you are trying to deploy, either here or privately?

Thanks!

[Jorge Ardila]

Hi Paul.

Thanks for the information shared via DM.

Based on your current configuration, the following paths should not be mounted as RW:

• /var/ossec/etc

• /var/ossec (entire directory)

These paths should remain read-only, using the files included in the container image. Mounting volumes over them will hide the original files and may cause unexpected behavior.

What SHOULD be mounted as RW:

Only runtime data paths where Wazuh needs write access should be mounted:

• /var/ossec/logs

• /var/ossec/queue

• /var/ossec/var

• /var/ossec/tmp

• /var/ossec/stats (if applicable)

Here is an example of a correct configuration (conceptual)

security:
  read_only_root_filesystem: true

volumes:
  - name: wazuh-logs
    mount: /var/ossec/logs
    readonly: false

  - name: wazuh-queue
    mount: /var/ossec/queue
    readonly: false

  - name: wazuh-var
    mount: /var/ossec/var
    readonly: false

  - name: wazuh-tmp
    mount: /var/ossec/tmp
    readonly: false

Best regards,
Jorge Ardila

[Jorge Ardila]

Hi Paul,

Thanks for your last reply. For future communications, please also include the group wa...@googlegroups.com.

Regarding your last comment, here are a few key points to clarify what you should expect:

• When you mount a volume on paths such as /var/ossec/logs, /var/ossec/queue, or /var/ossec/var, the volume will start empty. This is normal behavior in Kubernetes. The original directories from the image are not deleted; they are simply hidden by the mount.
• Wazuh will automatically recreate the required subdirectories (such as alerts, archives, etc.) once the services start and begin processing data.

Regarding restarts:

• Restarting the pod is sufficient.
• A manual systemctl restart wazuh-manager inside the container is usually not required and may not apply, depending on how the container is started.

Please let me know if, once Wazuh is running, the volumes are being written to or not.

Thanks.

[Paul Charran]

Jorge,

   I am getting the volumes that need to be r/w working. But, I am running into an interesting issue. Some of the Wazuh software checks to see if certain files are available, and if they are not, it causes an error. Since the volumes are formed blank I am having to manually (I am writing a service to install these files) add the files to get past these checks. These files are files in name only. They are blank. And I am afraid I may be missing some important information. 

   Now if I understand our earlier conversations the Volumes don't erase the original files they just provide a mount with a similar structure for Wazuh to write to. Kind of like an overlay. My question is, if those original files are still there somewhere, is there a way to copy them from the 'hidden/read-only' directory to the corresponding read / write volume?

Thanks in advance for any insight you might provide.

[Paul Charran]

Jorge,

   Thanks for the info on mounting directories on the same line. I took out all the child volumes. But, that puts me back in the barrel I started with. 

   For example I create a volume for /var/ossec/etc/lists I get critical error messages like Could not open file  etc/lists/audit-keys. I get the same error etc/lists/security -eventchannel and etc/lists/amazon/aws-eventnames. For that last one the amazon directory is not created under lists in the read / write volume. It's like the processes that create those things has passed and will not create these files on restart.

   I see this come up under other directories like /var/ossec/var/run and /var/ossec/queue. In order to clear the the errors I used touch to create the files the software was looking for. But those files are dummies. Size 0. I just want to make sure I don't cause more problems than I correct.

  Thanks,

      Paul

---

From: Jorge Ardila <jorge....@wazuh.com>
Sent: Tuesday, February 3, 2026 6:14 PM
To: Paul Charran <pcharr...@gmail.com>
Subject: Re: Private message regarding: using read_only_root_filesystem

 

Hi Paul, 

I'm going to write the message in the google group post, but first I need to know if you are still having issues with the configuration.

Answering to the previous email, Yes — mounting both /var/ossec/var and /var/ossec/var/run as separate volumes can cause conflicts.

In Kubernetes, when you mount a volume on a parent directory (for example /var/ossec/var), and then mount another volume on a subdirectory of that path (such as /var/ossec/var/run), the second mount can override or block what the application expects from the first one. This can result in issues like Wazuh being unable to create PID files.

For Wazuh, the recommended approach is:

• Mount only the parent directory /var/ossec/var as writable.

• Do not mount /var/ossec/var/run separately.

Wazuh will automatically create the run directory and the required PID files inside /var/ossec/var once the service starts, as long as the permissions are correct.

Finally, I apologize for the late response.

Best regards.

On Tue, Feb 3, 2026 at 10:13 AM Paul Charran <pcharr...@gmail.com> wrote:

Jorge,

  I think I forgot to add   wa...@googlegroups.com to my last e-mail. Could you forward it to the group? Or should I re-write my post?

Thanks,

  Paul

[Jorge Ardila]

Hi Paul.

The folder  /var/ossec/etc and any subfolder included there should not be mounted as RW, because these paths contain configuration and static data that must come from the image and should remain read-only

Best regards.

[Paul Charran]

I am trying to understand how this system works. I did back up to all the high level directories. Are the read/write status from the parent supposed to trickle down to the branches 

Now I have run into a catch-22. If I create a volume for /var/ossec/etc I get an error message saying the program cannot read ossec.conf. And if I don't create a volume to /var/ossec/etc/shared then I get an error message that the program cannot read ar.conf. When I create a R/W volume, that directory seems to be empty. We earlier described these volumes as an overlay but they seem to block access to the original read only directories. 

And I know that we discussed that lists does not need to be a volume but I am getting error messages like, Could not open file 'etc/lists audit-keys.tmp'. I get the same error for security-eventchannel.tmp and /amazon/aws-eventnames.tmp. As far as I can tell this is a reference to /var/ossec/etc/lists. 

This is happening with several directories. I tried to provide some clear examples so that the community can try to replicate my issues. I find it hard to believe this task is impossible. Otherwise why would the read-only-root-filesystem option be available. Hopefully someone has some insight or possibly a guide on how to make this transition. 

Thank you,

  Paul