@george1421 it is a racktop production filesystem,
the server “heads” are from racktop
I don’t know what filesystem is under that.

The senior sysadmin is looking into creating the share on that system.

I will let you know once I can continue working on this.

Thank again

@clickwir Any news on this?

Hey

I found out where my error came from, here are the settings:

Follow the tutorial of @george1421
https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node/16

On the Fog Web server

On Nas Synology, here is the NFS configuration on all the files /volume1/images /volume1/tftpboot /volume1/snapins so that all posts find sharing Thanks @hfredh

Thanks to all
One can pass the subject in solved

I keep you informed if I can deploy with this method normally there should be no problem

@+

What has changed in your environment between now and the last time you were able to image? Server change? DHCP change? New firewall? Perhaps it’s an IP Conflict? Did the V-LAN assigned to the fog server change?

Have you tried a different host? Are all hosts doing this?

And the final question is, do you have a reason why you are still using .32 ?

x32 bit machines should now be fixed in the latest git.

x32 Upload times are slow but they will upload all the way. ~84Mib/s with lvl 9 compression (4:20:15) x32 Download times are “fast” ~1.8Gib/s lvl 9 compression (00:12:01) x64 Up 3.2Gib/s lvl9 (00:20:00) Down 7.3Gib/s lvl9 (00:09:00)

Full Description of problem:
1.)nfs mount issue was due to not getting an ip address during init boot.
2.)Not getting an ip was due to an addition of fixing VLAN issues for networks and sleep command was an “Illegal Instruction” (along with other commands essential to “init fog script”)
3.)sleep was not working due to a compiling issue in the glibc v2.21.

*Solution:
1.) Downgraded init’s to use glibc v2.20 (fixed sleep function).
2.) init’s now get ips from edits in files K40Network and S40Network.
3.)NFS mounts successfully now that init gets an ip address at boot.

These changes have been pushed to both init_32.xz and init.xz.

If you see this issue with your old 32 bit only processors please make sure you update to the latest version and this should be fixed.

P.S. @Tom-Elliott thanks for the remote sessions and time. Took us a while but we nailed down the problem