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.