8

Thanks to the people here, the solution is quite simple (but not obvious): My GNU/Linux container host has SELinux activated, and that's why I was having permissions problems. The solution is to simply append a :z to the podman run volume argument so that this: podman run -it -v /host/foobar:/src_dir /bin/bash becomes this: podman run -it -v /host/foobar:...


3

It depends on what your persistentVolumeReclaimPolicy is. If you manually created/defined the PersistentVolume, then the default action is to keep the data. (This sounds like what you're doing.) If you are using something like EKS on Amazon, your PV's are dynamically generated EBS volumes. In that case, they will be deleted by default. A little bit more ...


2

The following setup works for me. When using the subPath in volumeMounts, the permission issue is automatically addressed, as the user postgres owns the folder corresponding to the subPath. spec: ... containers: - ... volumeMounts: # need a subpath as postgres wants an empty folder (the mounted folder `/var/lib/...


2

Did you try by specifying a storageClassName since Kubernetes will be using default storage class when it's not specified? See Dynamic Provisioning of the blog post and Dynamic from Kubernetes documentation? Or try with by removing the default storageclass in the cluster to explicitly use given PV and PVC configuration.


1

In my opinion, you could create bucket (aws s3 for example) and store your data there (create simple app to make upload), thus, you don’t need to care with disk full error


1

There's apparently 2 methods one can use to leverage tridentctl to interact with a running Trident Pod in their Openshift/Kubernetes cluster. 1. Server string The tridentctl CLI can be instructed to talk to whatever server you want remotely using the -s or --server argument. In this context you could use the approach of remote shelling into the Trident Pod ...


Only top voted, non community-wiki answers of a minimum length are eligible