# Unable to start Auditbeat on LXC container **URL:** \ **Category:** Beats\ **Tags:** auditbeat\ **Created:** [February 15, 2018, 6:27am UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913 "2018-02-15T06:27:17Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Luq](https://avatars.discourse-cdn.com/v4/letter/l/82dd89/32.png) [@Luq](https://discuss.elastic.co/u/Luq)\ **Post date:** [February 15, 2018, 6:27am UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913/1 "2018-02-15T06:27:17Z")
Hi, I've searched here but couldn't find a similar issue. I'm trying to run Auditbeat on CentOS 7 and it fails to start. Log only has this: "root@kibana1:~# cat /var/log/auditbeat/auditbeat 2018-02-15T06:23:21.005Z INFO instance/beat.go:468 Home path: [/usr/share/auditbeat] Config path: [/etc/auditbeat] Data path: [/var/lib/auditbeat] Logs path: [/var/log/auditbeat] 2018-02-15T06:23:21.005Z INFO instance/beat.go:475 Beat UUID: deed9a2c-39f1-4fd9-8617-b1a9ae15aa0b 2018-02-15T06:23:21.005Z INFO instance/beat.go:213 Setup Beat: auditbeat; Version: 6.2.1 2018-02-15T06:23:21.006Z INFO pipeline/module.go:76 Beat name: kibana1 2018-02-15T06:23:21.006Z INFO [auditd] auditd/audit\_linux.go:65 auditd module is running as euid=0 on kernel=4.13.0-32-generic 2018-02-15T06:23:21.007Z ERROR instance/beat.go:667 Exiting: 1 error: 1 error: failed to create audit client: failed to get audit status: connection refused When I do auditbeat test output it passes "root@kibana1:~# auditbeat test output logstash: 10.221.233.193:5043... connection... parse host... OK dns lookup... OK addresses: 10.221.233.193 dial up... OK TLS... WARN secure connection disabled talk to server... OK but when I try to do auditbeat test config it fails. I checked config file and there is nothing that stands out. I enabled kibana and logstash output. I did also manually exported indexes to Elasticsearch node. Any ideas where I'm going wrong? Thanks ---
**Author:** ![exekias](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/exekias/32/28718_2.png) [@exekias](https://discuss.elastic.co/u/exekias)\ **Post date:** [February 15, 2018, 8:25am UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913/2 "2018-02-15T08:25:18Z")
Hi @Luq, Did you define any rules? Is the `auditd` process running? Depending on your settings it may be interfering with Auditbeat. Check the docs here: [https://www.elastic.co/guide/en/beats/auditbeat/6.2/auditbeat-module-auditd.html](https://www.elastic.co/guide/en/beats/auditbeat/6.2/auditbeat-module-auditd.html). Please paste your config if you don't find a fix there 🙂 Best regards ---
**Author:** ![Luq](https://avatars.discourse-cdn.com/v4/letter/l/82dd89/32.png) [@Luq](https://discuss.elastic.co/u/Luq)\ **Post date:** [February 15, 2018, 10:03am UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913/3 "2018-02-15T10:03:56Z")
Thanks for quick response! I learned a few things. Firstly, I didn't have auditd installed on the system. After I installed it, I couldn't get it to start. I'm blaming container for that. I'm supposing it's something to do with it being in the container because the error I get when I try to run it is: root@centos-7 ~]# /sbin/auditd -f Config file /etc/audit/auditd.conf opened for parsing local\_events\_parser called with: yes write\_logs\_parser called with: yes log\_file\_parser called with: /var/log/audit/audit.log log\_group\_parser called with: root log\_format\_parser called with: RAW flush\_parser called with: INCREMENTAL\_ASYNC freq\_parser called with: 50 max\_log\_size\_parser called with: 8 num\_logs\_parser called with: 5 priority\_boost\_parser called with: 4 qos\_parser called with: lossy dispatch\_parser called with: /sbin/audispd name\_format\_parser called with: NONE max\_log\_size\_action\_parser called with: ROTATE space\_left\_parser called with: 75 space\_action\_parser called with: SYSLOG action\_mail\_acct\_parser called with: root admin\_space\_left\_parser called with: 50 admin\_space\_left\_action\_parser called with: SUSPEND disk\_full\_action\_parser called with: SUSPEND disk\_error\_action\_parser called with: SUSPEND use\_libwrap\_parser called with: yes tcp\_listen\_queue\_parser called with: 5 tcp\_max\_per\_addr\_parser called with: 1 tcp\_client\_max\_idle\_parser called with: 0 enable\_krb5\_parser called with: no krb5\_principal\_parser called with: auditd distribute\_network\_parser called with: no Cannot change priority (Operation not permitted) The audit daemon is exiting. ---
**Author:** ![exekias](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/exekias/32/28718_2.png) [@exekias](https://discuss.elastic.co/u/exekias)\ **Post date:** [February 15, 2018, 10:51am UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913/4 "2018-02-15T10:51:28Z")
So this `centos-7` is a container? Could you explain a little bit about your setup? ---
**Author:** ![Luq](https://avatars.discourse-cdn.com/v4/letter/l/82dd89/32.png) [@Luq](https://discuss.elastic.co/u/Luq)\ **Post date:** [February 15, 2018, 11:53am UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913/5 "2018-02-15T11:53:15Z")
I'm running LXD on Ubuntu. I have 4 containers one for elasticsearch, one for kibana, one for logstash - all running ubuntu, and one for centos system. I got it to work where I can see the logs in Kibana coming from centos filebeat. But when I tried to install and set up auditbeat, I came across that issue. I also tried auditbeat on ubuntu container and it also failed with the same error. ---
**Author:** ![exekias](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/exekias/32/28718_2.png) [@exekias](https://discuss.elastic.co/u/exekias)\ **Post date:** [February 15, 2018, 12:19pm UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913/6 "2018-02-15T12:19:41Z")
It looks like a permissions error, probably related to capabilities? I just checked Auditbeat guide to run it on docker and there are some capabilities you need in place: [https://www.elastic.co/guide/en/beats/auditbeat/6.x/running-on-docker.html](https://www.elastic.co/guide/en/beats/auditbeat/6.x/running-on-docker.html) I'm not very familiar with LXD, are you dropping any of those? ---
**Author:** ![Luq](https://avatars.discourse-cdn.com/v4/letter/l/82dd89/32.png) [@Luq](https://discuss.elastic.co/u/Luq)\ **Post date:** [February 16, 2018, 8:12am UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913/7 "2018-02-16T08:12:05Z")
Yes, my understanding is that since lxc containers run as unprivileged it doesn't allow auditd to run. I think case with Docker is a little different. Also, I'm not sure what you are referring to "are you dropping any of those?" Well, if I comment out audit module in auditbeat.yml file and leave file integrity module, it works fine. I'll just suffice with Filebeat, I guess. Thanks for your help! ---
**Author:** ![andrewkroh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrewkroh/32/3784_2.png) [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)\ **Post date:** [February 16, 2018, 11:35pm UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913/8 "2018-02-16T23:35:00Z")
> [@Luq](#): > > I learned a few things. Firstly, I didn't have auditd installed on the system. Auditbeat does not have any dependencies on the Linux `auditd` package. In fact in most cases `auditd` must be stopped for Auditbeat's auditd module to function correctly. If both are running Auditbeat will log an error and tell you to stop the auditd process. > [@Luq](#): > > 2018-02-15T06:23:21.006Z INFO [auditd] auditd/audit\_linux.go:65 auditd module is running as euid=0 on kernel=4.13.0-32-generic > > 2018-02-15T06:23:21.007Z ERROR instance/beat.go:667 Exiting: 1 error: 1 error: failed to create audit client: failed to get audit status: connection refused Based on the logs you are running Auditbeat as root which is good. But the Linux kernel has a few other requirements for user-space processes that try to connect to the kernel's audit framework. This makes it tricky to run any audit deamon inside of a container. One requirement for the process is that it be in the initial PID namespace. The other requirements are that the process have the AUDIT\_CONTROL and AUDIT\_READ capabilities. I'm not familiar enough with LXD to be able to provide guidance on how to ensure that the containerized process meets those requirements. ---
**Author:** ![Jose\_E](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jose_e/32/47012_2.png) [@Jose\_E](https://discuss.elastic.co/u/Jose_E)\ **Post date:** [January 27, 2020, 9:08am UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913/9 "2020-01-27T09:08:43Z")
I'm having the same issue and I'm afraid docker is not an option... Did you ever find a solution for this? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [November 4, 2022, 5:13am UTC](https://discuss.elastic.co/t/unable-to-start-auditbeat-on-lxc-container/119913/10 "2022-11-04T05:13:59Z")