QNAP and Rancher, A Match Made in Permissions Hell

 

I've been running some services that utilize AI Agents and wanted to request history for the agents to use and while there are several types of storage to use, PostgreSQL is one of the most recommended.   Since I'm only using it to provide limited history I didn't want to run a full VM to host the server and hosting PostgreSQL storage over NFS is frowned upon in this establishment.    We required non-network filesystem storage.  (yes, I get the irony here)

So, I wanted to provide an ext4 / xfs persistent volume for my PostgreSQL server, but didn't want to just do writethrough to the physical host which I don't backup.  I do on the other hand backup my NAS and since I do that.  Seems like a good location to storage my pgdata.

My primary stack (at this moment anyhow) is Proxmox running Rocky Linux VMs running a SUSE Rancher Kubernetes cluster utilizing a QNAP NAS for storage.

To utilize the QNAP, there is a QNAP CSI Driver for Kubernetes that seem to fit the bill.  I went through the process of installing the plugin, but alas.  It wouldn't start.  It presented several errors and I would work through them only to end up back at the first error and there was no Kubernetes "Service" created as the pods failed to start.

The issue ended up being focused around Rancher permissions preventing the pods from starting.

time="2025-06-23T16:04:05Z" level=error msg="error syncing 'trident': error installing Trident using CR 'trident' in namespace 'trident'; err: reconcile failed; failed to patch Trident installation namespace trident; admission webhook \"rancher.cattle.io.namespaces\" denied the request: Unauthorized, requeuing"

 Following that error, it then provided the following two errors.

level=info msg="No Trident deployments found by label." label="app=controller.csi.trident.qnap.io" namespace=trident

and...

 level=info msg="No Trident daemonsets found by label." label="app=node.csi.trident.qnap.io" namespace=trident

While a tried a few things to resolve this, I did end up going to the developers and it seems someone just previous to me had the same issue and was able to use a workaround to resolve it by running the following command:

kubectl label namespaces trident pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/audit=privileged pod-security.kubernetes.io/warn=privileged

This labelling of the namespace effectively resolved the issue and allowed the plugin / service to be installed.