Troubleshooting Regional File Storage encryption in transit

Virtual Private Cloud

Use the following troubleshooting topics to resolve issues with Regional File Storage (RFS) encryption in transit (EIT).

RFS EIT is available as a Beta feature and is recommended for experimental use only. Do not use this feature in production workloads.

Why is my PVC stuck in Pending with 'rfs' profile is not accessible?

Your PVC remains in Pending state after creation, and you see an error similar to the following in the PVC events.

'rfs' profile is not accessible

Your account might not be allowlisted for the rfs profile, or your cluster might not have the required IAM permissions for VPC file share operations.

To resolve the issue:

  1. Check the PVC events to confirm the error.

    kubectl describe pvc <pvc-name>

    Look for 'rfs' profile is not accessible in the Events section. If this error is present, your account needs to be allowlisted for the rfs profile.

  2. If the error is 'rfs' profile is not accessible, open a VPC support ticket to request access. After your account is allowlisted, restart the CSI driver node pods.

    kubectl rollout restart daemonset ibm-vpc-file-csi-node -n kube-system

  3. If the PVC shows permission-related errors instead, verify that your cluster has the required IAM permissions for VPC file share operations.

Why does my pod fail to mount with stunnel manager is not initialized?

Your pod shows a FailedMount event with an error similar to the following.

stunnel manager is not initialized, this indicates a configuration error.
Restart the file csi node server pod from kube-system namespace where the
application is running and check if the issue is resolved.

The stunnel manager on the CSI node server pod on the affected worker node is not initialized, which indicates a configuration error on that node.

To resolve the issue:

  1. Find the CSI node server pod that is running on the same node as your application pod. Note the node name where your pod is scheduled.

    kubectl get pod <app-pod-name> -o wide

  2. Get the CSI node server pod running on that node.

    kubectl get pods -n kube-system -l app=ibm-vpc-file-csi-node \
  --field-selector spec.nodeName=<node-name>

  3. Delete the CSI node server pod so that it restarts automatically.

    kubectl delete pod -n kube-system <csi-node-pod>

  4. Wait for the pod to restart and reach Running state, then retry your application pod.

    kubectl get pods -n kube-system -l app=ibm-vpc-file-csi-node

    If the issue persists after the pod restarts, open a support ticket with the IBM Cloud Container Storage team.

Why does my application with hostNetwork: true fail to bind a port?

An application pod that uses hostNetwork: true fails at startup with the following error.

Address already in use

RFS EIT binds one port per PVC mount in the range 11300–11599 on 127.0.0.1. An application pod that uses hostNetwork: true and tries to bind to a port in this range conflicts with an existing RFS EIT PVC mount on the same node.

To resolve the issue, choose one of the following options:

  • Scale down all applications that use RFS EIT file shares, then scale them back up. After scaling up, the application pods pick up different ports from the allocation range, and the conflict is resolved.
  • Access the application through a Kubernetes Service resource instead of relying on host ports with hostNetwork: true. This avoids the port conflict entirely.