EntitlementBootstrap failure preventing startup: AttachNotSupportedException: Unable to open socket file

Elastic Stack Elasticsearch
57

@RainTown I’m not a k8s or efs expert, but I think the settings are found here:

GitHub - kubernetes-sigs/aws-efs-csi-driver: CSI Driver for Amazon EFS https://aws.amazon.com/efs/.

So the way I played around with this is to create a persistent volume claim that requests the EFS CSI driver for a volume. In that claim/request, you specify a storage class. In that storage class config, you specify the parameters listed in the link above. In the one I’m tinkering with, I just have

parameters:
  directoryPerms: "700"
  ensureUniqueDirectory: "false"
  fileSystemId: <redacted>
  provisioningMode: efs-ap

Because an uid/gid is not explicitly set, gidRangeStart/End will be used, so my understanding is that the gid range will be between 50000-7000000 (the defaults). I don’t see an equivalent UID range setting, but uid = gid for all files created in this volume mount. And yes, for every new PVC requested we get a seemingly different gid.

My favorite LLM tells me that the behavior of UID/GID ownership for files in the EFS volume will not correspond to current user / creator / euid and that is just the behavior of EFS since it doesn’t have mappings to linux IDs. I am not a file system expert, but that feels odd to me since this isn’t a problem with other types of volumes.

The workarounds are:

a) use -XX:+StartAttachListener as you noted

b) set uid/gid to the elasticsearch user in the storageclass specified by the PVC. This makes it so all files created in the volume will be the one expected by the attach thread. This will work, but our customers never had to do that before so I’m not sure we’ll recommend doing this. I feel like I’d opt to use the startAttachListener flag that you noted to make the fix invisible to customers. Setting the uid/gid in the storageclass also may be conflicting with a reason our customers wanted dynamic gids to be used in the first place - some research tells me having the gids being unique may actually be a security / workload isolation feature that is desired.

c) as noted before, setting runAsUser and fsGroup to just match the uid/gid ownership on the EFS volume, but that isn’t a great solution because someone may have other volumes and other types of volumes needed by elasticsearch that will conflict with this dynamic gid

1 Like