FOG NFS Challenge: Can you do it?


  • Moderator

    From a client Linux system, using the mount command,

    Can you mount your FOG server’s /images/dev directory and then upload a file to it?

    Winner gets a hand-written “Congratulations & Thank You” note/picture from me, forever hosted in this thread. :-)

    Information

    Local directory to mount to:

    [CODE]/FOGdev[/CODE]

    Mounting commands tried so far (where 10.0.0.3 is my home FOG server):

    [CODE]mount -t nfs 10.0.0.3:/images/dev/ /FOGdev
    mount -t nfs -o rw,remount 10.0.0.3:/images/dev/ /FOGdev
    mount 10.0.0.3:/images/dev /FOGdev
    mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.0.0.3:/images/dev/ /FOGdev
    mount -o rw,nolock 10.0.0.3:/images/dev /FOGdev
    mount -o rw 10.0.0.3:/images/dev /FOGdev[/CODE]

    After mounting, I try:
    [CODE]cd /FOGdev
    touch test[/CODE]

    And I get this error every single time:
    [CODE]touch: cannot touch ‘test’: Read-only file system[/CODE]


  • Moderator

    For future readers,

    to test without using the debug deployment (just using a LIVE CD instead),

    inside /etc/exports on the FOG server,
    Set the fsid for /images to 0 and /images/dev to 1

    Save that, exit that, then run this:
    exportfs -a

    (got all that info from Tom)

    Expect a completed “Troubleshoot NFS” article soon!

    And some of my terrible artwork for Tom, too. lol


  • Senior Developer

    @Wayne-Workman said:

    @Tom-Elliott said:

    @Wayne-Workman Ummm, have them upgrade to 3473…

    ha! well then… dang…

    I suppose they will need to use the debug deployment to test NFS…

    I really want a work around…

    I really think that would be the best work around. We know all worked in the init, so boot to debug an blam, you have yourself a way to test if nfs is at least working.


  • Moderator

    @Tom-Elliott said:

    @Wayne-Workman Ummm, have them upgrade to 3473…

    ha! well then… dang…

    I suppose they will need to use the debug deployment to test NFS…

    I really want a work around…


  • Senior Developer

    @Wayne-Workman Ummm, have them upgrade to 3473…


  • Moderator

    Tom, that’s just great!

    However, my troubleshooting article will now only work for those with r3473 or later.

    Any way at all to get something to work with r3472 or earlier? The troubleshooting article ought to help out 1.2.0 users at the least.


  • Senior Developer

    Exports was setup slightly improperly.

    It was assigning the subtree options (which we really don’t want and/or need) so the fsid

    If a path is given (e.g. mountpoint=/path or mp=/path) then the nominated path must be a mountpoint for the exportpoint to be exported.
    fsid=num|root|uuid
    NFS needs to be able to identify each filesystem that it exports. Normally it will use a UUID for the filesystem (if the filesystem has such a thing) or the device number of the device holding the filesystem (if the filesystem is stored on the device).
    As not all filesystems are stored on devices, and not all filesystems have UUIDs, it is sometimes necessary to explicitly tell NFS how to identify a filesystem. This is done with the fsid= option.
    
    For NFSv4, there is a distinguished filesystem which is the root of all exported filesystem. This is specified with fsid=root or fsid=0 both of which mean exactly the same thing.
    
    Other filesystems can be identified with a small integer, or a UUID which should contain 32 hex digits and arbitrary punctuation.
    
    Linux kernels version 2.6.20 and earlier do not understand the UUID setting so a small integer must be used if an fsid option needs to be set for such kernels. Setting both a small number and a UUID is supported so the same configuration can be made to work on old and new kernels alike.
    

    Basically what this means, the fsid needs to be directed at filesystem UUID, or UID of a valid user. Setting to 1 and 2 ordered it, but the subtree would make it so the previous (root or /images in our case) was opened under the user with UID 1 which likely doesn’t have valid permissions. On our init’s there is a userID to UID 1 and 2, but they don’t point to the same as a normal distro so they always assumed root, but on distro’s this is not the same. On the init’s UID 1 is mapped to the daemon user which likely has a link to the root user directly, while UID 2 is linked to the bin user. Most likely these two users don’t actually exist anywhere on the system and therefor it defaults back to the root user. This is just a guess. Either way, the installer should fix this for us now.


  • Moderator

    It didn’t help…

    [CODE][root@D620 administrator]# mount -t nfs 10.0.0.3:/images/dev/ /FOGdev
    [root@D620 administrator]# cd /FOGdev
    [root@D620 FOGdev]# touch test
    touch: cannot touch ‘test’: Read-only file system
    [root@D620 FOGdev]# mkdir test
    mkdir: cannot create directory ‘test’: Read-only file system
    [root@D620 FOGdev]# ssh 10.0.0.3
    root@10.0.0.3’s password:
    Last login: Mon May 25 13:00:14 2015 from 10.0.0.12
    [root@localhost ~]# cat /etc/exports
    /images/dev *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=1)
    /images *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=2)
    /opt/fog/clamav *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=3)
    [root@localhost ~]# servcie xinetd restart
    -bash: servcie: command not found
    [root@localhost ~]# service nfs restart
    Redirecting to /bin/systemctl restart nfs.service
    [root@localhost ~]# service rpcbind restart
    Redirecting to /bin/systemctl restart rpcbind.service
    [root@localhost ~]# exit
    logout
    Connection to 10.0.0.3 closed.
    [root@D620 FOGdev]# cd …
    [root@D620 /]# umount /FOGdev
    [root@D620 /]# mount -t nfs 10.0.0.3:/images/dev/ /FOGdev
    [root@D620 /]# cd /FOGdev
    [root@D620 FOGdev]# touch test
    ^C
    [root@D620 FOGdev]# mkdir test
    mkdir: cannot create directory ‘test’: Read-only file system
    [root@D620 FOGdev]# ls
    [root@D620 FOGdev]# ls -a
    . … .mntcheck
    [root@D620 FOGdev]# [/CODE]


  • Moderator

    I will try that,

    but the purpose of this is to finalize the WiKi article I’m working on, “Troubleshoot NFS”.

    Ideally, the standard options for a basic self-contained 1.2.0 FOG server should work and not need changed… somehow…

    Somehow, a host can upload an image to /images/dev… Just need to figure out how to do that from a regular Linux Live CD.



  • What about swapping the order they’re listed?


  • Moderator

    Earlier today, Tom was helping me via TeamViewer to solve this.

    He did swap out the IDs, and it didn’t work.



  • It’s been a while since I last spent much time dealing with the rules of NFS; but I seem to recall there being a thing about subdirectory rules being inherited, and some searching around the web points to swapping your fsid’s for /images and /images/dev so that /images/dev is processed first.

    Not really sure if that will solve anything, and I don’t have a linux box on hand to test with, but it looks plausible.


  • Moderator

    @BryceZ said:

    Did you check /etc/exports on 10.0.0.3 to make sure that it has write permissions?

    Sure did. I can upload images via FOG just fine on my home’s FOG server.

    Here are the contents:

    [CODE][root@localhost ~]# cat /etc/exports
    /images *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1)
    /images/dev *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2)
    /opt/fog/clamav *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=3)
    [root@localhost ~]# [/CODE]

    The real question here is, can YOU figure out how to mount and upload a file from a regular Linux Live CD, or from a regular client Linux machine ?



  • Did you check /etc/exports on 10.0.0.3 to make sure that it has write permissions?


Log in to reply
 

408
Online

38970
Users

10712
Topics

101667
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.