Mounting file system: Failed. Uploading my first image

[Sebastian Roth]

@Miguel-Palacios There is one thing I noticed:

*/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev (rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

Just a typo with the ‘*’?? It should be like this - please check your /etc/exports again:

/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

As well please post the output of sudo iptables -L -n -v on your FOG server here!

[Miguel Palacios]

@Sebastian-Roth Sorry, when I tried write in italics the system “it ate” the asterisk… The /etc/exports seems be correct. Also I show here the output of sudo iptables -L -n -v

[george1421]

@Miguel-Palacios OK, it looks like the FOS client is OK on that target computer.

(step next…)

On the FOG server lets see if we can map itself (also answer Sebastians’s question about iptables).

mount -t nfs <fog_server_ip>:/images /mnt

That should mount the fog servers /images share over the top of the /mnt directory. If you cd /mnt you should see the same content as in the /images folder.

Just so I don’t forget disconnect this mount with umount /mnt.

Have you rebooted this FOG server since you started having a problem? This issue is very strange indeed.

[Sebastian Roth]

I suggest using the nolock option when mounting NFS: mount -t nfs -o nolock <fog_server_ip>:/images /mnt

[Miguel Palacios]

@george1421 and @Sebastian-Roth, the command mount working with itself:

Yes, I have restarted several times, incluse I resintalled the system… U_U

[Sebastian Roth]

@Miguel-Palacios Then try the exact same mount command from the client again! In debug mode that is!

[Miguel Palacios]

@Sebastian-Roth the problem continues…

[Quazz]

@Miguel-Palacios Hi, can you run exportfs -r on your FOG Server, post the output here and try again on the FOGclient? (if it doesn’t work, try exportfs -r a second time)

[Miguel Palacios]

Hi @Quazz , this command executed in the server not show nothing… is it normal?

[Quazz]

@Miguel-Palacios I believe it only gives output if there’s an error, so that’s good news already.

[george1421]

@Miguel-Palacios Please provide the output of sudo iptables -L -n -v

[Miguel Palacios]

@Quazz I have executed other new capture task and the error is the same that my first post
On the other hand, of new, I have executed other new capture task (with debug activate) and I have executed the command mount but this again returned the same error.
In the side server, the command exportfs -r continues without show nothign…

[Quazz]

@Miguel-Palacios What’s the output of rpcinfo -p?

[Miguel Palacios]

@george1421 here it’s

[Miguel Palacios]

@Quazz the result for rpcinfo -p

[george1421]

@Miguel-Palacios said in Mounting file system: Failed. Uploading my first image:

@george1421 here it’s

Sorry for being stubborn here, but what you are seeing is not logical. I don’t doubt it is happening, its just confusing.

[Miguel Palacios]

@george1421 I am in the same situation…

Say you that the FOG server is installed in a virtual machine on VMware ESXi 5.5.0 (3116895)… I don’t know if this detail shed light at problem…

[george1421]

@Miguel-Palacios I had my fog servers on centos 6.5 running on vmware 5.5 for over a year. This Jan I rebuilt the server using centos 7 and the current fog trunk. Both worked without issue. Now that I think about it, I have a dev fog server that is still running centos 6.5/6.7. I may need to power it on so we can compare services or what ever.

[Miguel Palacios]

@Sebastian-Roth I attached the result for our test.

0_1459517616214_nfs.pcap

[Sebastian Roth]

The PCAP file is showing a perfect connect form client to server on port 111 (portmap) to get the NFS port. Then… silence. After some more digging and testing it turns out that an intermediate cisco switch is causing the problem!