Seeing this error : /opt/CrowdStrike/falcon-daemonset-init: No such file or directory

[sagnikundu]

We are experiencing issues deploying falcon-sensor on Azure.

Getting this error :

kubectl logs -f falcon-sensor-daemonet-pod -n falcon-system -c init-falconstore
..
Running /opt/CrowdStrike/falcon-daemonset-init -i
/bin/bash: line 1: /opt/CrowdStrike/falcon-daemonset-init: No such file or directory

There are few things which we would like to highlight.

The version 1.29.1 of the chart chart doesn’t have volume mounts for the init container which is present on older version (1.26.1) of the chart deployed on our AWS clusters. We think this might be the reason for the error below, since the path or directory required during the init-container execution is absent. We need to understand what’s happening here. Below is the diff highlighted between the old and new chart.

snippet :

Older chart : 1.26.1
initContainers:
- args:
- '-c'
- >-
if [ -x "/opt/CrowdStrike/falcon-daemonset-init" ]; then echo
"Running falcon-daemonset-init -i" ;
/opt/CrowdStrike/falcon-daemonset-init -i ; else if [ -d
"/host_opt/CrowdStrike/falconstore" ] ; then echo "Re-creating
/opt/CrowdStrike/falconstore as it is a directory instead of a
file"; rm -rf /host_opt/CrowdStrike/falconstore; fi; mkdir -p
/host_opt/CrowdStrike && touch /host_opt/CrowdStrike/falconstore;
fi
command:
- /bin/bash
image: >-
052113251141.dkr.ecr.us-east-1.amazonaws.com/falcon-sensor:7.11.0-16405-1.falcon-linux.x86_64.Release.US-1
imagePullPolicy: Always
name: init-falconstore
resources: {}
securityContext:
allowPrivilegeEscalation: true
privileged: true
readOnlyRootFilesystem: false
runAsUser: 0
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /host_opt
name: falconstore-dir

New Chart : 1.29.1 ( No volume mounts )
initContainers:
- args:
- '-c'
- >-
echo "Running /opt/CrowdStrike/falcon-daemonset-init -i";
/opt/CrowdStrike/falcon-daemonset-init -i
command:
- /bin/bash
image: >-
ciacrapp001.azurecr.io/falcon-sensor:7.18.0-5704.container.x86_64.Release.US-1
imagePullPolicy: Always
name: init-falconstore
resources: {}
securityContext:
allowPrivilegeEscalation: true
privileged: true
readOnlyRootFilesystem: false
runAsUser: 0
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File

[redhatrises]

Hello,

Please make sure that you are using the correct sensor image as the sensor image you are using in the new chart won't work because it is the sidecar sensor and not the daemonset sensor

[sagnikundu]

Thanks , I could bring the daemonset up with sensor image : falcon-sensor:7.18.0-17106-1.falcon-linux.Release.US-1

I could see this directory get created : /opt/CrowdStrike , but the init container still was in crashloop. I had to create the file manually : /opt/CrowdStrike/falconstore ,with permission : 755 , to make it work.

The older chart had taken into account of creating this file which is absent on the current daemonset manifest. Not sure why this is removed.

[redhatrises]

/opt/CrowdStrike/falconstore should not be a directory and shouldn't have permissions 755. I would probably suggest cleaning up /opt/CrowdStrike by removing it entirely, and then redeploying. The falcon-daemonset-init takes care of the /opt handling now.

[herself]

I've ran into the same problem. Also have this directory present. I'm running v1.30 of this chart with the 7.21.0-6003 sensor. Clean install. Any idea how to debug this further?

[Huang-W]

@herself @redhatrises It's a bug in the helm chart introduced by this commit: 018b260

The init-container creates file at /opt/Crowdstrike/falconstore, but it's created in container filesystem.

When init-container stops, and container starts up, the file doesn't exist anymore.

To fix the bug, add volumeMount to initContainer, like is done with container

[cappscolton]

Here's @Huang-W 's change in a PR. Fixed the issue for us.
#399

[robrides]

Hello,

Please make sure that you are using the correct sensor image as the sensor image you are using in the new chart won't work because it is the sidecar sensor and not the daemonset sensor

Just to expound on this point, using the bash script, use the -t option and specify falcon-sensor if you're using the daemonset. No changes to the init container config needed. Also, just to confirm as I only saw reference in a discussion, this does deploy succesffully on AWS EKS auto mode ref: bottlerocket.