@clintkitson was kind enough to toss in on rexray/rexray#1114 and once it was clear how to specify options, a lot more made sense.

That said, I think there may be a compatibility issue with the plugin as I built up in rexray/rexray#1114 (comment) over several comments. The mount is happening, but at a directory name that includes a :. Docker seems to be parsing that and dropping the colon and everything after it as it tries to map the external volume.

It's unclear how to specify a mount option such as sec=sys. When using a NFSv4 volume from a modern operating system, the negotiation will naturally take the highest level of security that is available.

Unfortunately, if that resolves to krb5, an arbitrary container is unlikely to have a ticket or the ability to acquire one. In that case, the contents of the volume will either be inaccessible or mapped to nobody. sec=sys is not ideal, but sufficient in a controlled security context.

Apologies if this is already addressed and I missed it in the documentation.

Create 'service' package that REX-Ray can use to import csi-nfs, and have it register a gRPC server with REX-Ray.

Right now the NFS plugin is mounting directly to the requested path. The desired workflow is what is implemented in blockdevices already, which is to mount the volume in a private directory, then to bind-mount the volume to target. It is likely that logic from blockdevices can be re-used.

Hi,

I think it makes sense to update the Gopkg.toml file with a specific commit hash for GoCSI:

[[constraint]]
  branch = "master"
  name = "github.com/codedellemc/gocsi"

I'd switch branch for version (which is recommended by the Gopkg docs) and point to a specific Git ref or tag. Otherwise this is a sliding dependency that will change every time the lock file is updated from the toml file.

i was able to create the volume with docker. But now i want to use that volume in a kubernetes cluster.

[root@csi-nfs-node1 docker]# docker volume create -d rexray/csi-nfs -o host=xxxxxx -o export=/data csi-nfs-volume

[root@csi-nfs-node1 docker]# docker volume ls
DRIVER VOLUME NAME
rexray/csi-nfs:latest csi-nfs-volume

I created both a pv and pvc. I notice that kubernetes does not like the driver name rexray/csi-nfs, so i removed rexray.

When i go to launch my nginx pod, it can't mount the volume. Wondering if anyone else tried it.
Thanks..

apiVersion: v1
kind: PersistentVolume
metadata:
creationTimestamp: null
labels:
io.kompose.service: csi-data-volume
name: csi-data-volume
spec:
storageClassName: manual
capacity:
storage: 100Mi
accessModes:

• ReadWriteOnce
  csi:
  driver: csi-vfs
  volumeHandle: csi-volume

apiVersion: v1
kind: PersistentVolume
metadata:
creationTimestamp: null
labels:
io.kompose.service: csi-data-volume
name: csi-data-volume
spec:
storageClassName: manual
capacity:
storage: 100Mi
accessModes:

• ReadWriteOnce
  csi:
  driver: csi-vfs
  volumeHandle: csi-nfs-volume

apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:

• name: nginx
  image: nginx:1.7.9
  ports:
  • containerPort: 80
    volumeMounts:
  • mountPath: "/work"
    name: data-volume
    volumes:
  • name: data-volume
    persistentVolumeClaim:
    claimName: csi-nfs-data-claim
    status: {}

sorry,Wrong question, please close。

I am looking for a way to do persistent storage for docker swarm, and understand that Rex-Ray and csi-nfs could be a solution. However, I only have access to a cifs drive.

Would it be possible to extend this driver to support other types of network filesystems as well? I guess it is just a matter of doing a few changes to the code.

Today I tried to test the csi-nfs as a storage plugin, according to the README.md document, seem below csc command is out of date:

$ csc gets
0.0.0
$ csc getp -version 0.0.0
csi-nfs	0.1.0
$ csc cget -version 0.0.0
LIST_VOLUMES
$ showmount -e 192.168.75.2
Exports list on 192.168.75.2:
	/data                             192.168.75.1
$ mkdir /mnt/test
$ csc mnt -version 0.0.0 -targetPath /mnt/test -mode 1 host=192.168.75.2 export=/data
$ ls -al /mnt/test
total 1
drwxr-xr-x   2 root  wheel    18 Jul 22 20:25 .
drwxrwxrwt  85 root  wheel  2890 Aug 17 15:32 ..
-rw-r--r--   1 root  wheel     0 Jul 22 20:25 test
$ csc umount -version 0.0.0 -targetPath /mnt/test host=192.168.75.2 export=/data
$ ls -al /tmp/mnt
total 0
drwxr-xr-x   2 travis  wheel    68 Aug 16 15:01 .
drwxrwxrwt  85 root    wheel  2890 Aug 17 15:32 ..

The output of the csc in my system is:

# csc
NAME
    csc -- a command line container storage interface (CSI) client

SYNOPSIS
    csc [flags] CMD

AVAILABLE COMMANDS
    controller
    identity
    node

Use "csc -h,--help" for more information