NFS example: unable to mount the service #24249

Smana · 2016-04-14T12:39:53Z

Hi guys,

I just noticed that i'm not able to mount the nfs service as described in the nfs example.
Mounting using the pod's ip works fine:

kubectl describe po nfs-server-e6qzy | grep ^IP
IP:     10.233.127.3

mount.nfs 10.233.127.3:/ /mnt

cat /mnt/index.html
Hello from NFS!

But when i use the service it doesn't work

kubectl get svc | grep nfs
nfs-server   10.233.45.48   <none>        2049/TCP   2m

mount.nfs 10.233.45.48:/ /mnt
mount.nfs: Connection timed out

There are no error logs in the kube-proxy logs:

I0414 12:28:50.569854       1 proxier.go:415] Adding new service "default/nfs-server:" at 10.233.45.48:2049/TCP
I0414 12:28:50.569999       1 proxier.go:360] Proxying for service "default/nfs-server:" on TCP port 49291

kubectl get endpoints  | grep nfs
nfs-server   10.233.127.3:2049   8m

The forwarding rule seems to be configured:

DNAT       tcp  --  0.0.0.0/0            10.233.45.48         /* default/nfs-server: */ tcp dpt:2049 to:10.128.0.2:49291

This has been reproduced with flannel and calico on GCE and baremetal.
I'm going to try with the proxy-mode = iptables, though i don't know if that will change anything.
Do you have any idea ?

The text was updated successfully, but these errors were encountered:

Smana · 2016-04-14T12:55:25Z

Same behavior with iptables mode.

Further info.
Same errors after completing the steps:

kubectl get pvc
NAME      STATUS    VOLUME    CAPACITY   ACCESSMODES   AGE
nfs       Bound     nfs       1Mi        RWX           20m

kubectl describe po nfs-busybox-txf6o | tail -n 10

Output: mount.nfs: Connection timed out


  21s   21s 1   {kubelet smana-p8j480}      Warning FailedSync  Error syncing pod, skipping: Mount failed: exit status 32
Mounting arguments: 10.233.45.48:/ /var/lib/kubelet/pods/bf41d3f1-023f-11e6-8ab8-42010a800002/volumes/kubernetes.io~nfs/nfs nfs []
Output: mount.nfs: Connection timed out

ncdc · 2016-04-14T15:58:12Z

When I tested this a few days ago, if I waited long enough (5 to 10 minutes), the timeout error eventually went away and everything was good. Do you see the same behavior?

cc @kubernetes/sig-network @kubernetes/rh-networking

ovanes · 2016-04-14T17:12:46Z

Env: AWS + Kuberentes 1.2.0:

I probably found the bug/problem for this. I had same issues with redis-cluster bootstrap. IMO it has smth to do with the iptable rules. If I create an RC and throw in a few more instances of the same pod everything works fine.

I saw that the load balancer was implemented with iptables as well. Here the comparisons:

Single POD + Service DOES NOT WORK:

$ sudo iptables-save | grep redis-cluster
-A KUBE-SEP-3HO5IUUYYOQYCOWC -s 10.2.8.2/32 -m comment --comment "default/redis-cluster:" -j KUBE-MARK-MASQ
-A KUBE-SEP-3HO5IUUYYOQYCOWC -p tcp -m comment --comment "default/redis-cluster:" -m tcp -j DNAT --to-destination 10.2.8.2:30001
-A KUBE-SERVICES -d 10.3.0.233/32 -p tcp -m comment --comment "default/redis-cluster: cluster IP" -m tcp --dport 30001 -j KUBE-SVC-MFCTP2GDPQP4R6UC
-A KUBE-SVC-MFCTP2GDPQP4R6UC -m comment --comment "default/redis-cluster:" -j KUBE-SEP-3HO5IUUYYOQYCOWC

Multiple PODS + Service WORKS:

$ sudo iptables-save | grep redis-ha
-A KUBE-SEP-HOO27LVK6N73KSOO -s 10.2.32.2/32 -m comment --comment "default/redis-ha:" -j KUBE-MARK-MASQ
-A KUBE-SEP-HOO27LVK6N73KSOO -p tcp -m comment --comment "default/redis-ha:" -m tcp -j DNAT --to-destination 10.2.32.2:26380
-A KUBE-SEP-QLVDFURI7RZHXDPY -s 10.2.31.2/32 -m comment --comment "default/redis-ha:" -j KUBE-MARK-MASQ
-A KUBE-SEP-QLVDFURI7RZHXDPY -p tcp -m comment --comment "default/redis-ha:" -m tcp -j DNAT --to-destination 10.2.31.2:26380
-A KUBE-SEP-TVDFKNQ4EIEH4WFO -s 10.2.72.2/32 -m comment --comment "default/redis-ha:" -j KUBE-MARK-MASQ
-A KUBE-SEP-TVDFKNQ4EIEH4WFO -p tcp -m comment --comment "default/redis-ha:" -m tcp -j DNAT --to-destination 10.2.72.2:26380
-A KUBE-SERVICES -d 10.3.0.64/32 -p tcp -m comment --comment "default/redis-ha: cluster IP" -m tcp --dport 26380 -j KUBE-SVC-2XOQJ6XFWENJIX4U
-A KUBE-SVC-2XOQJ6XFWENJIX4U -m comment --comment "default/redis-ha:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-QLVDFURI7RZHXDPY
-A KUBE-SVC-2XOQJ6XFWENJIX4U -m comment --comment "default/redis-ha:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-HOO27LVK6N73KSOO
-A KUBE-SVC-2XOQJ6XFWENJIX4U -m comment --comment "default/redis-ha:" -j KUBE-SEP-TVDFKNQ4EIEH4WFO

Single POD promoted with RC to multiple PODs WORKS:

$ sudo iptables-save | grep redis-cluster
-A KUBE-SEP-3HO5IUUYYOQYCOWC -s 10.2.8.2/32 -m comment --comment "default/redis-cluster:" -j KUBE-MARK-MASQ
-A KUBE-SEP-3HO5IUUYYOQYCOWC -p tcp -m comment --comment "default/redis-cluster:" -m tcp -j DNAT --to-destination 10.2.8.2:30001
-A KUBE-SEP-B75DDUYBXPQEQ3V2 -s 10.2.72.3/32 -m comment --comment "default/redis-cluster:" -j KUBE-MARK-MASQ
-A KUBE-SEP-B75DDUYBXPQEQ3V2 -p tcp -m comment --comment "default/redis-cluster:" -m tcp -j DNAT --to-destination 10.2.72.3:30001
-A KUBE-SEP-YXAYEQKMTKJHNTKU -s 10.2.31.3/32 -m comment --comment "default/redis-cluster:" -j KUBE-MARK-MASQ
-A KUBE-SEP-YXAYEQKMTKJHNTKU -p tcp -m comment --comment "default/redis-cluster:" -m tcp -j DNAT --to-destination 10.2.31.3:30001
-A KUBE-SERVICES -d 10.3.0.233/32 -p tcp -m comment --comment "default/redis-cluster: cluster IP" -m tcp --dport 30001 -j KUBE-SVC-MFCTP2GDPQP4R6UC
-A KUBE-SVC-MFCTP2GDPQP4R6UC -m comment --comment "default/redis-cluster:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-YXAYEQKMTKJHNTKU
-A KUBE-SVC-MFCTP2GDPQP4R6UC -m comment --comment "default/redis-cluster:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-B75DDUYBXPQEQ3V2
-A KUBE-SVC-MFCTP2GDPQP4R6UC -m comment --comment "default/redis-cluster:" -j KUBE-SEP-3HO5IUUYYOQYCOWC

Actually, SVC even does not redirect packets to the last POD.

Even RC with one instance makes the service hang.

bprashanth · 2016-04-14T18:00:50Z

You can't access yourself through your Service VIP in iptables kube-proxy (i.e 1 endpoint Svc, kubectl exec into endpoint, curl svc ip won't work) without either hairpin mode on all your veth's (for intf in /sys/devices/virtual/net/cbr0/brif/*; do cat $intf/hairpin_mode; done) or a promiscuous mode cbr0 (netstat -i).

bprashanth · 2016-04-14T18:03:23Z

The default cluster setup should give you promiscuous mode. We had a bug in between where we weren't defaulting to old hairpin behavior, but that should be fixed with: #23325. What hairpin-mode is you kubelet operating with (it's a flag you can find via ps | grep)?

ncdc · 2016-04-14T18:04:35Z

@bprashanth for my test, I had:

nfs service
nfs server pod
nfs pv
pvc
client pod using pvc

Are you saying that should not work by default?

erinboyd · 2016-04-14T18:05:33Z

Are you using nfsv3 or nfsv4?

bprashanth · 2016-04-14T18:16:21Z

As long as the client pod is talking to the Service VIP that's talking to the nfs server pod (and these 2 are different pods), hairpin mode doesn't matter. It only matters if you're talking to a service that loadbalances back to the same pod. I couldn't make out if that was what @ovanes was asking about.

All setups should work by default. There was a window (before #23325, after 1.2) where one configuration didn't work (i.e if you're running with --configure-cbr0=false but still using a linux bridge), for the specific hairpin mode case.

ncdc · 2016-04-14T19:35:25Z

@bprashanth yes, that's what I have (client pod -> service VIP -> nfs server pod). The first time it attempted to mount the PV into the client pod, it failed (connection timed out). I then waited several minutes and it magically cleared up and was able to connect and mount.

thockin · 2016-04-14T19:56:32Z

There's noting in the iptables dumps that indicates that there's a bug - it all looks exactly as I expect it to.

http://docs.k8s.io/user-guide/debugging-services might apply, though I r ealize it needs an update for iptables.

ovanes · 2016-04-14T21:14:30Z

@bprashanth Indeed, talking to the service from a non-service related container distributes load to all containers. Thanks for clarification.

innovia · 2016-04-15T15:23:57Z

Im having the same issue, after being forced to delete all the nodes (would not unmount EBS) when nodes were recreated with labels, and since then it fails for me too on connection timeout

the pod itself listen to 2049 and 111

telnet from inside the nfs-server pod to the service works, but from busybox it doesn't

telnet nfs-server 2049
Trying 10.0.119.174...
Connected to nfs-server.
Escape character is '^]'.
^]
telnet> q
Connection closed.
[root@nfs-server-d89jg /]# exit

kubectl exec -it busybox  -- sh                                                                                             

/ # telnet nfs-server 2049
^C (ctrl c cause it hangs)

innovia · 2016-04-17T08:31:47Z

the nfs image is messed up - bring up your own nfs-server and it works fine

if you need to tweak the mount points other than exports look at any entrypoint for any nfs-server
docker file out there

Dockerfile:

FROM ubuntu:14.04

ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update -qq  \
    && apt-get install -y nfs-kernel-server nfs-common \  \
    && mkdir /exports \
    && echo "/exports *(rw,fsid=0,insecure,no_root_squash)" >> /etc/exports \
    && echo "Serving /exports" \
    && /usr/sbin/exportfs -a

EXPOSE 111/udp 2049/tcp

COPYCOPY nfs-kernel-server /etc/default/
 /etc/default/
COPY run.sh /run.sh
ENTRYPOINT  [ "/run.sh" ]

run.sh

#!/bin/bash
echo "Starting NFS Server"

rpcbind
service nfs-kernel-server start

echo "Started"

echo "Done all tasks - Running continious loop to keep this container alive"
while true; do
  sleep 3600
done

nfs-kernel-server:

# Number of servers to start up
RPCNFSDCOUNT=8

# Runtime priority of server (see nice(1))
RPCNFSDPRIORITY=0

# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option. For more information,
# see rpc.mountd(8) or http://wiki.debian.org/SecuringNFS
# To disable NFSv4 on the server, specify '--no-nfs-version 4' here
RPCMOUNTDOPTS="--port 20048 --no-nfs-version 4"

# Do you want to start the svcgssd daemon? It is only required for Kerberos
# exports. Valid alternatives are "yes" and "no"; the default is "no".
NEED_SVCGSSD=""

# Options for rpc.svcgssd.
RPCSVCGSSDOPTS=""

# Options for rpc.nfsd.
RPCNFSDOPTS=""

UPDATE: 5/22/2017

in order to have NFS successfully mount via a service you need to make sure all its ports are fixes and not dynamically assigned.

check what ports are published by rpc by connecting to the running NFS server pod:
(in the example below this is done after I've fixed the mountd port to static)

kubectl exec -it nfs-server-3989555812-rrbct -- bash

$(POD) rpcinfo -p

   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100227    3   tcp   2049
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100227    3   udp   2049
    100021    1   udp  58681  nlockmgr
    100021    3   udp  58681  nlockmgr
    100021    4   udp  58681  nlockmgr
    100021    1   tcp  42438  nlockmgr
    100021    3   tcp  42438  nlockmgr
    100021    4   tcp  42438  nlockmgr
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd

nfs_server_service.yaml

kind: Service
apiVersion: v1
metadata:
  name: nfs-server
spec:
  ports:
    - name: nfs
      port: 2049
    - name: mountd
      port: 20048
    - name: rpcbind
      port: 111
    - name: rpcbind-udp
      port: 111
      protocol: UDP
  selector:
    role: nfs-server

check that you can mount to the the pod directly
mount.nfs -v POD_IP:/exports /location_to_mount

to unmount a disconnected / dead pod volume use
umount -l /mount_location (-l lazy umount)

then check that the service is mounting:
mount.nfs -v SERVICE_IP:/exports /location_to_mount

mount.nfs: timeout set for Sun May 21 14:19:04 2017
mount.nfs: trying text-based options 'vers=4,addr=100.71.151.43,clientaddr=172.20.178.222'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=100.71.151.43'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 100.71.151.43 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 100.71.151.43 prog 100005 vers 3 prot UDP port 20048
mount.nfs: portmap query retrying: RPC: Timed out
mount.nfs: prog 100005, trying vers=3, prot=6
mount.nfs: trying 100.71.151.43 prog 100005 vers 3 prot TCP port 20048

jingxu97 · 2016-12-15T20:07:18Z

Hi NFS users, the support of NFS on GCI image is not available on release 1.4.7 and 1.5. Please give it a try and let us know if you have any problem. Thanks!

groundnuty · 2017-03-08T13:19:50Z

I have tried a couple of nfs-server images from docker hub, I've built and image based on what @innovia supplied above. I've used Deployment, tried 1 and many replicas. In all cases, I can access the nfs servers when using pods ip-s, but not service ip.

Running k8s 1.5.3 on bare-metal ubuntu setup with kubeadm.

jingxu97 · 2017-03-08T18:08:38Z

@groundnuty could you provide more details about your setup? Also could you try to use service name? I have a simple setup which uses service name and it works for me.

Glusterfs Pod

apiVersion: v1
kind: Pod 
metadata:
  name: gluster-server
  labels:
    k8s-app: glusterfs
spec:
  containers:
  - name: gluster-server
    image: gcr.io/google_containers/volume-gluster:0.5
    ports:
      - name: gluster
        hostPort: 24007
        containerPort: 24007
        protocol: TCP
      - name: glusters
        hostPort: 49152
        containerPort: 49152
        protocol: TCP
      - name: glusterfs
        hostPort: 24008
        containerPort: 24008
        protocol: TCP

Glusterfs Service

kind: Service
metadata:
  name: gluster-service
  labels:
    app: mine
spec:
  ports:
    - port: 24007
      name: gluster
      protocol: TCP
  selector:
    k8s-app: glusterfs

Gluster client

apiVersion: v1
kind: Pod
metadata:
  name: gluster-client
  labels:
    name: gluster
spec:
  containers:
  - name: app-pod
    image: redis 
    volumeMounts:
    - name: webapp 
      mountPath: /gluster
  volumes:
  - name: webapp
    glusterfs:
      endpoints: gluster-service
      path: "test_vol"
      readOnly: false

maclof · 2017-03-08T18:24:04Z

@jingxu97 how is that at all related? You're talking about GlusterFS, not NFS.

jingxu97 · 2017-03-08T18:48:48Z

the way to mount NFS and GLusterFS is very similar. It would be very helpful if you could provide more details about your set up so that I can have a try to see the problem. Thanks!

groundnuty · 2017-03-08T21:50:18Z

@jingxu97 I was not able to test glusterfs (need to install some packages on nodes to make it work), but after modifying your example for NFS it seems to be working well.

As some people here tested this against single pod and multiple-pod setups, I provide single and multiple files for testing.

To be fair I don't know why it started to work. My own usecase also works now. The only thing I did was to install on all nodes (and master): glusterfs-client and glusterfs-common. All nodes are running Ubuntu 16.04. UPDATE: Uninstalled both packages from all nodes, still working.

IMPORTANT: Please modify nfs volume server field in the client pods so that it matches the service.

Single pod test:

---
#Single NFS Server Pod
apiVersion: v1
kind: Pod
metadata:
  name: nfs-server
  labels:
    k8s-app: nfs-pod
    tag: nfs-pod-test
spec:
  containers:
  - name: nfs-server
    image: gcr.io/google-samples/nfs-server:1.1
    ports:
      - name: nfs
        hostPort: 2049
        containerPort: 2049
        protocol: TCP
      - name: mountd
        hostPort: 20048
        containerPort: 20048
        protocol: TCP
      - name: rpcbind
        hostPort: 111
        containerPort: 111
        protocol: TCP
    securityContext:
      privileged: true
---
#Single Pod NFS Service
kind: Service
metadata:
  name: nfs-pod-service
  labels:
    k8s-app: nfs-pod
    tag: nfs-pod-test
spec:
  ports:
    - name: nfs
      port: 2049
      protocol: TCP
    - name: mountd
      port: 20048
      protocol: TCP
    - name: rpcbind
      port: 111
      protocol: TCP
  selector:
    k8s-app: nfs-pod
    tag: nfs-pod-test
---
#Single Pod NFS client
apiVersion: v1
kind: Pod
metadata:
  name: nfs-pod-client
  labels:
    name: nfs-pod-client
    tag: nfs-pod-test
spec:
  containers:
  - name: app-pod
    image: redis
    volumeMounts:
    - name: webapp
      mountPath: /mnt
  volumes:
  - name: webapp
    nfs:
      # FIXME: The ip or domain of nfs-pod-service
      server: nfs-pod-service.default.svc.cluster.local
      path: "/exports"
      readOnly: false

Multiple pods test:

---
#Group of NFS Server Pods
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nfs-servers
  labels:
    k8s-app: nfs-pods
    tag: nfs-pods-test
spec:
  replicas: 3
  template:
    metadata:
      name: nfs-server
      labels:
        k8s-app: nfs-pods
        tag: nfs-pods-test
    spec:
      containers:
      - name: nfs-server
        image: gcr.io/google-samples/nfs-server:1.1
        ports:
          - name: nfs
            containerPort: 2049
          - name: mountd
            containerPort: 20048
          - name: rpcbind
            containerPort: 111
        securityContext:
          privileged: true
---
#Group of Pods NFS Service
kind: Service
metadata:
  name: nfs-pods-service
  labels:
    app: mine
    tag: nfs-pods-test
spec:
  ports:
    - name: nfs
      port: 2049
      protocol: TCP
    - name: mountd
      port: 20048
      protocol: TCP
    - name: rpcbind
      port: 111
      protocol: TCP
  selector:
    k8s-app: nfs-pods
    tag: nfs-pods-test
---
#Group of Pods NFS client
apiVersion: v1
kind: Pod
metadata:
  name: nfs-pods-clientt
  labels:
    name: nfs-pods-client
    tag: nfs-pods-test
spec:
  containers:
  - name: app-pod
    image: redis
    volumeMounts:
    - name: webapp
      mountPath: /mnt
  volumes:
  - name: webapp
    nfs:
      # FIXME: The ip or domain of nfs-pods-service
      server: nfs-pods-service.default.svc.cluster.local
      path: "/exports"
      readOnly: false

kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.3", GitCommit:"029c3a408176b55c30846f0faedf56aae5992e9b", GitTreeState:"clean", BuildDate:"2017-02-17T20:49:14Z", GoVersion:"go1.8", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.4", GitCommit:"7243c69eb523aa4377bce883e7c0dd76b84709a1", GitTreeState:"clean", BuildDate:"2017-03-07T23:34:32Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

fejta-bot · 2017-12-24T22:36:40Z

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

fejta-bot · 2018-01-23T23:25:02Z

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

fejta-bot · 2018-02-22T23:30:52Z

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

xiaokugua250 · 2019-01-09T02:40:26Z

i found a new way to solve this problem ,you can set nfs-server port to be fixed ,then mount nfs-server by service . you can refer to https://wiki.debian.org/SecuringNFS.

lavalamp added sig/storage Categorizes an issue or PR as relevant to SIG Storage. team/cluster labels Apr 14, 2016

thockin added team/sig-aws and removed team/sig-aws labels Aug 12, 2016

justinsb self-assigned this Nov 15, 2016

jingxu97 mentioned this issue Mar 13, 2017

glusterfs volumes not working on GKE #40180

Closed

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 24, 2017

k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jan 23, 2018

k8s-ci-robot closed this as completed Feb 22, 2018

Dan-Zi mentioned this issue Nov 23, 2021

nfs-client-provisioner Pod are getting failed kubernetes-sigs/nfs-subdir-external-provisioner#102

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NFS example: unable to mount the service #24249

NFS example: unable to mount the service #24249

Smana commented Apr 14, 2016

Smana commented Apr 14, 2016

ncdc commented Apr 14, 2016

ovanes commented Apr 14, 2016

bprashanth commented Apr 14, 2016

bprashanth commented Apr 14, 2016 •

edited

Loading

ncdc commented Apr 14, 2016

erinboyd commented Apr 14, 2016

bprashanth commented Apr 14, 2016

ncdc commented Apr 14, 2016

thockin commented Apr 14, 2016

ovanes commented Apr 14, 2016 •

edited

Loading

innovia commented Apr 15, 2016 •

edited

Loading

innovia commented Apr 17, 2016 •

edited

Loading

jingxu97 commented Dec 15, 2016

groundnuty commented Mar 8, 2017

jingxu97 commented Mar 8, 2017

maclof commented Mar 8, 2017

jingxu97 commented Mar 8, 2017

groundnuty commented Mar 8, 2017 •

edited

Loading

fejta-bot commented Dec 24, 2017

fejta-bot commented Jan 23, 2018

fejta-bot commented Feb 22, 2018

xiaokugua250 commented Jan 9, 2019

NFS example: unable to mount the service #24249

NFS example: unable to mount the service #24249

Comments

Smana commented Apr 14, 2016

Smana commented Apr 14, 2016

ncdc commented Apr 14, 2016

ovanes commented Apr 14, 2016

bprashanth commented Apr 14, 2016

bprashanth commented Apr 14, 2016 • edited Loading

ncdc commented Apr 14, 2016

erinboyd commented Apr 14, 2016

bprashanth commented Apr 14, 2016

ncdc commented Apr 14, 2016

thockin commented Apr 14, 2016

ovanes commented Apr 14, 2016 • edited Loading

innovia commented Apr 15, 2016 • edited Loading

innovia commented Apr 17, 2016 • edited Loading

Dockerfile:

run.sh

nfs-kernel-server:

UPDATE: 5/22/2017

nfs_server_service.yaml

jingxu97 commented Dec 15, 2016

groundnuty commented Mar 8, 2017

jingxu97 commented Mar 8, 2017

maclof commented Mar 8, 2017

jingxu97 commented Mar 8, 2017

groundnuty commented Mar 8, 2017 • edited Loading

fejta-bot commented Dec 24, 2017

fejta-bot commented Jan 23, 2018

fejta-bot commented Feb 22, 2018

xiaokugua250 commented Jan 9, 2019

bprashanth commented Apr 14, 2016 •

edited

Loading

ovanes commented Apr 14, 2016 •

edited

Loading

innovia commented Apr 15, 2016 •

edited

Loading

innovia commented Apr 17, 2016 •

edited

Loading

groundnuty commented Mar 8, 2017 •

edited

Loading