TrueNAS as storage for OpenShift using TrueNASCSI

TrueNAS General
1

Hello,

I have a problem connecting my OpenShift 4.22.2 cluster (3-node bare-metal) to my TrueNAS Scale 25.10.4 System with iSCSI.
The TrueNAS iSCSI Target lives on 192.168.10.126 and it allows all initiators on the 192.168.10.0/24 subnet (to keep it simple for now).
It has a iscsi IQN Base called “iqn.2005-10.org.freenas.ctl”

The OpenShift Nodes all live in this 192.168.10.0 / 24 network as well, so there are no firewalls etc.

First, I created the “truenas-csi” namespace manually in the OpenShift WebConsole.
(this instruction is missing from the documentation on the GitHub Page by the way. Applying the “secret yaml” will therefore fail because that namespace does not exist yet at this step.
Not sure if the “TrueNAS CSI Driver v1.0.0” operator should have created that namespace during install, but it didn’t, so I had to create it manually)

I then created a user inside TrueNas calles “OpenShiftUser” and gave it full admin rights and generated a API key. I verified that this user has API access.
Then I created a yaml for this secret and “oc applied” it. Then check it’s presence with “oc get secret truenas-api-credentials -n truenas-csi -o yaml” and it looks correct.

I then created the yaml for the TrueNASCSI custom resource to deploy the CSI driver:

apiVersion: csi.truenas.io/v1alpha1
kind: TrueNASCSI
metadata:
  name: truenas
spec:
  insecureSkipTLS: false
  iscsiIQNBase: "iqn.2005-10.org.freenas.ctl"
  credentialsSecret: "truenas-api-credentials"
  namespace: truenas-csi
  iscsiPortal: "192.168.10.126:3260"
  defaultPool: "Pool01"
  truenasURL: "wss://192.168.10.126/api/current"

I then oc apply it with “oc apply -f truenas-csi.yaml” and check it with “oc get truenascsi truenas -o yaml”.
This is the output:

apiVersion: csi.truenas.io/v1alpha1
kind: TrueNASCSI
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"csi.truenas.io/v1alpha1","kind":"TrueNASCSI","metadata":{"annotations":{},"name":"truenas"},"spec":{"credentialsSecret":"truenas-api-credentials","defaultPool":"Pool01","insecureSkipTLS":false,"iscsiIQNBase":"iqn.2005-10.org.freenas.ctl","iscsiPortal":"192.168.10.126:3260","namespace":"truenas-csi","truenasURL":"wss://192.168.10.126/api/current"}}
  creationTimestamp: "2026-07-04T22:42:52Z"
  finalizers:
  - csi.truenas.io/finalizer
  generation: 1
  name: truenas
  resourceVersion: "467692"
  uid: 7338f7b2-689a-4761-9316-8800e5a7ee35
spec:
  controllerReplicas: 1
  credentialsSecret: truenas-api-credentials
  defaultPool: Pool01
  driverImage: quay.io/truenas_solutions/truenas-csi:latest
  insecureSkipTLS: false
  iscsiIQNBase: iqn.2005-10.org.freenas.ctl
  iscsiPortal: 192.168.10.126:3260
  logLevel: 4
  managementState: Managed
  namespace: truenas-csi
  truenasURL: wss://192.168.10.126/api/current
status:
  conditions:
  - lastTransitionTime: "2026-07-04T22:42:52Z"
    message: Waiting for controller and node components to be ready
    reason: WaitingForComponents
    status: "True"
    type: Progressing
  driverVersion: latest
  observedGeneration: 1
  phase: Pending

and that’s how it stays for hours.
I get no errors.
but it keeps saying “Waiting for controller and node components to be ready” and remains in the “pending” state.

I checked if the target on TrueNAS is live and working by abusing a Windows server machine on the same subnet and using it’s software iSCSI to discover the TrueNAS and that all works (I allowed all initiators to the iSCSI target which is why this works without any problems)

To verify that all 3 OpenShift Cluster Nodes can reach port 3260 of the TrueNAS, I used these commands:

oc debug node/<a node> -- chroot /host bash -c \
  "nc -zv 192.168.10.126 3260"

and that responds with:

Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.10.126:3260.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

when I test with this (I found this on the internet somewhere):

oc run test-ws --rm -it --image=curlimages/curl -- \
  curl -k wss://192.168.10.126/api/current

I get this on all 3 nodes after waiting for a minute of silence:

imac:~ steven$ oc run test-ws --rm -it --image=curlimages/curl -- \
>   curl -k wss://192.168.10.126/api/current
All commands and output from this session will be recorded in container logs, including credentials and sensitive information passed through the command prompt.
If you don't see a command prompt, try pressing enter.
curl: (52) Empty reply from server
Session ended, resume using 'oc attach test-ws -c test-ws -i -t' command when the pod is running
pod "test-ws" deleted from default namespace

It’s the reply “curl: (52) Empty reply from server” that catches my attention.

I must be missing something :frowning:

Documentation that I used:
github dot com/truenas/truenas-csi/blob/master/docs/openshift/installation.md
github dot com/truenas/truenas-csi/blob/master/docs/openshift/configuration.md

As well as the relevant documentation on the TrueNAS Website and various blogs and posts.

Disclaimer: I’ve been working with Linux since 1995 and I’m a long-time TrueNAS user, but i’m a total OpenShift and Container noob. This is my first shot at OpenShift.

Kind regards,
Steve

3

Hi Zappo,

Good news, your setup is closer than it looks. Nothing’s actually wrong with the API.

The curl -k (52) Empty reply from server result is a bit of a red herring. Exit code 52 actually means curl did connect and complete the TLS handshake, it just got no HTTP body back, which is normal when you point a plain curl at a WebSocket JSON-RPC endpoint (it’s waiting for the client to send a message first). If the API were truly unreachable you’d see “connection refused” or a timeout instead. So your nodes can reach the box just fine.

The real cause is the -k in your curl. That flag tells curl to skip certificate verification, but your CR has insecureSkipTLS: false, so the driver does not skip it. TrueNAS ships a self-signed cert by default, which the driver doesn’t trust, so its connection fails silently and retries forever. That’s why the operator sits at “Waiting for controller and node components to be ready” with no obvious error. Set insecureSkipTLS: true in your TrueNASCSI resource and re-apply. The pods should go Ready shortly after.

Also thanks for the note about the namespace step missing from the docs, that’s a fair catch and we’ll get it added.

Let us know how it goes!

4

Good evening,

Thanks for the heads-up concerning the TLS check. I removed the CSI Driver, modified the yaml file and set that parameter to “true” and oc applied the yaml.

Unfortunately, no luck. It is still “Waiting for controller and node components to be ready” after 30 minutes or so.

imac:openshift steven$ oc get truenascsi truenas -o yaml
apiVersion: csi.truenas.io/v1alpha1
kind: TrueNASCSI
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{“apiVersion”:“csi.truenas.io/v1alpha1",“kind”:“TrueNASCSI”,“metadata”:{“annotations”:{},“name”:“truenas”},“spec”:{“credentialsSecret”:“truenas-api-credentials”,“defaultPool”:“Pool01”,“insecureSkipTLS”:true,“iscsiIQNBase”:“iqn.2005-10.org.freenas.ctl”,“iscsiPortal”:“192.168.10.126:3260”,“namespace”:“truenas-csi”,“truenasURL”:"wss://192.168.10.126/api/current”}}
creationTimestamp: “2026-07-06T20:14:21Z”
finalizers:

csi.truenas.io/finalizer
generation: 1
name: truenas
resourceVersion: “1576644”
uid: 91c01ce0-1c93-438a-a026-feae97f285e5
spec:
controllerReplicas: 1
credentialsSecret: truenas-api-credentials
defaultPool: Pool01
driverImage: 

insecureSkipTLS: true
iscsiIQNBase: iqn.2005-10.org.freenas.ctl
iscsiPortal: 192.168.10.126:3260
logLevel: 4
managementState: Managed
namespace: truenas-csi
truenasURL: wss://192.168.10.126/api/current
status:
conditions:

lastTransitionTime: “2026-07-06T20:14:23Z”
message: Waiting for controller and node components to be ready
reason: WaitingForComponents
status: “True”
type: Progressing
driverVersion: latest
observedGeneration: 1
phase: Pending

Anything else I can check? Logs?
(the logs “oc logs -n openshift-operators deployment/truenas-csi-operator-controller-manager“ , “oc logs -n truenas-csi deployment/truenas-csi-controller -c csi-controller“ and “oc logs -n truenas-csi daemonset/truenas-csi-node -c csi-node“ from the github pages, have no output at all, presumably because “nothing happened yet” so to speak).

I created that namespace manually with defaults. When I remember correctly, the WebGUI had me enter a name and the “labels” frame was pre-populated with “app=frontend” which I did not touch. As a default network policy I took the default of “no restrictions” because that made sense to me.
Was the namespace created correctly or should I have added something (in the labels field for example).

The make sure it’s not a iSCSI specific issue, I deleted the CSI again, made a copy of my yaml and modified that to “NFS only”. Again it applied without any errors but it too never leaves the “Waiting for controller and node components to be ready” state.
ofcourse, both NFS and iSCSI Services are running on the TrueNAS but NFS is largely un-configured (no exports). I just made sure the binding to the IP is correct.

I checked if the iSCSI Initiator software is present on all 3 bare-metal nodes and I’d say it is:

rpm -qa | grep -i iscsi
iscsi-initiator-utils-iscsiuio-6.2.1.11-0.git4b3e853.el9.x86_64
iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el9.x86_64

.
Another thing I noticed: The reason I use a yaml file on the CLI is because I cannot get the webgui to work. The “select secret” drop-down, where one should select the secret, stays empty on my system. Because I can’t select the secret I uploaded using a YAML, the GUI is not working for me so I turned to the CLI.

5

Update: to see if iSCSI works at all (fundamentally), I delete the CSI (it was still “waiting for controller and node components to be ready) and configured iSCSI the old fashioned way with normal iscsiadm.
That works fine. All three bare-metal nodes can login to the TrueNAS Target, on the TrueNAS i see them coming in as initiators, configure ZVOL/Extents to them, all good.

Example of one of the 3 nodes:

[root@oshiftnode01 ~]# sudo iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:nas01-iscsi01-vlan1 -l iface0 -l
Login to [iface: iface0, target: iqn.2005-10.org.freenas.ctl:nas01-iscsi01-vlan1, portal: 192.168.10.126,3260] successful.
[root@oshiftnode01 ~]# sudo iscsiadm -m session
tcp: [1] 192.168.10.126:3260,1 iqn.2005-10.org.freenas.ctl:nas01-iscsi01-vlan1 (non-flash)

So the problem is definitely not basic iSCSI connectivity. I hope you can help me further, as i’d like to use TrueNASCSI.