This message was deleted.

Specifically when I set up an NFS share on 3 K8S systems for /var/lib/longhorn (each using a different directory on the nfs server), I can't deploy a volume and get this message out of the longhorn manager pod:

time="2022-12-15T13:43:56Z" level=warning msg="Cannot auto salvage volume: no data exists" accessMode=rwx controller=longhorn-volume frontend=blockdev migratable=false node=ktest-k8-2 owner=ktest-k8-2 shareEndpoint= shareState=stopped state=detached volume=pvc-d549713d-a7da-4332-92ca-5ebecf7e0183

You really should not store the LH volumes on a NFS share. If you have NFS, you already have a persistent storage system somewhere and should rather use that directly. You'd need a dedicated NFS share for every node running LH, which seems ... a convoluted setup. What is the motivation for trying to put LH volumes on top of NFS?

I like the abstraction layer that longhorn provides (where users cannot directly access the underlying storage where volumes are kept) as opposed to direct NFS where users have numerous ways of accessing the back-end storage. I have another question in the #general channel about using NFS as back-end storage and getting around some of the permission openness. Do you have experience running NFS as a back-end with restrictive use? That's really what I'm ultimately after.

Yes, I think that's mostly what you should aim for, I'd think (unless you've got node-local storage that LH can leverage). And unfortunately, I don't have that experience with NFS servers in a k8s context, it probably also depends on the NFS service you're leveraging.

Thanks for the help