Menu

#100 NFS: listing /mnt/share locks whole directory

v0.671
open
7
2012-10-28
2006-07-05
ingo
No
  1. since I installed a local DNS-server and since
    FreeNAS 0.671 (including file locking) everything is
    almost perfect!

  2. one minor problem remains:
    the exported share here is /mnt/data.
    I can mount from all clients now (OS/2 uses locking), I
    can copy data in both directions, I can list the
    content of sub-directories, can list the files within
    /mnt/data using wildcards, and I can umount clean
    without any problems.
    However if I just mount and issue only a list-command
    for the share, like
    dir x:\ (x: is the letter /mnt/data is mapped to)
    then umount fails and the whole /mnt/data remains
    locked on FreeNAS and the only way to resolve that is a
    hard reset of the server.

Examples:
dir x:*.pos is ok
dir x:\backup is ok
dir x:\backup*.txt is ok

If on client side I change into that directory,
call dir .\backup and change back to a local drive all
is ok.

only dir x:\ (or just dir when x: is PWD) it displays
all content, and blocks the server
due to locked /mnt/data.

If furter info/test needed, please let me know,
best regards,
Ingo

Discussion

  • ingo

    ingo - 2006-07-07

    Logged In: YES
    user_id=1540519


    Solution found and tested, please consider for next release


    Hi Oliver,

    made a lot of tests now to find the root cause. I was guessing
    that the problem is only related to the fact that
    /mnt/sharename cannot be locked for NFS-access.

    What I did (sharename here is 'home', so default export was
    /mnt/home):

    created a subdirectory /mnt/sharename/ingo on the disk.

    with FreeNAS 0.671 up, I did download /etc/inc/services.inc

    did edit services.inc and substituted this line in NFS-section

    /mnt/{$mount['sharename']} -alldirs
    into
    /mnt/{$mount['sharename']}/ingo -alldirs

    to move the exported directory to /mnt/sharename/ingo

    restarted nfs services.

    On the client now showexp reports the new subdirectory
    and I can mount, copy files, call 'dir' command within the
    mounted directory, I can umount cleanly - all perfect!

    The only thing this hotfix is missing: it does not survive a
    reboot.
    But it definitely confirms my asumption that /mnt/sharename
    must not be locked, while subdirectories work correct.

    Would be great, if you can include this fix (actually no
    bug, but configuration issue) into next release of GREAT
    FreeNAS.
    Best way of course would be if on the NFS-configuration page
    in the web-browser you ask for the name of the subdirectory,
    create it and adopt services.inc accordingly.
    This way also feature requests from other uses "please make
    exported directory configurable" can be included as well.

    Comment (no current need):
    if besides rpc.lockd and rpc.statd you also add rpc.rquotad,
    NFS is complete and prepared for future multiuser-use with
    quotas for disc space.

    On NFS-configuration page or in the manual probably
    following hint is usefull to avoid 'help postings' in the
    forum:

    If yor NFS-client is using file-locking, please make sure
    that FreeNAS can resolve your clients hostname to IP-address
    and vice versa. This requires (at the moment) a running
    DNS-server in your LAN and FreeNAS must be configured to use
    this DNS-server. (later on FreeNAS may hold a /etc/hosts for
    the LAN or even provide a DNS-server itself;-)

    With best regards and awaiting the new release,
    Ingo

     
  • ingo

    ingo - 2006-07-07

    my patched 'services.inc' for NFS-locking

     
  • ingo

    ingo - 2006-07-07

    Logged In: YES
    user_id=1540519


    Solution found and tested, please consider for next release


    Hi Oliver,

    made a lot of tests now to find the root cause. I was guessing
    that the problem is only related to the fact that
    /mnt/sharename cannot be locked for NFS-access.

    What I did (sharename here is 'home', so default export was
    /mnt/home):

    created a subdirectory /mnt/sharename/ingo on the disk.

    with FreeNAS 0.671 up, I did download /etc/inc/services.inc

    did edit services.inc and substituted this line in NFS-section

    /mnt/{$mount['sharename']} -alldirs
    into
    /mnt/{$mount['sharename']}/ingo -alldirs

    to move the exported directory to /mnt/sharename/ingo

    restarted nfs services.

    On the client now showexp reports the new subdirectory
    and I can mount, copy files, call 'dir' command within the
    mounted directory, I can umount cleanly - all perfect!

    The only thing this hotfix is missing: it does not survive a
    reboot.
    But it definitely confirms my asumption that /mnt/sharename
    must not be locked, while subdirectories work correct.

    Would be great, if you can include this fix (actually no
    bug, but configuration issue) into next release of GREAT
    FreeNAS.
    Best way of course would be if on the NFS-configuration page
    in the web-browser you ask for the name of the subdirectory,
    create it and adopt services.inc accordingly.
    This way also feature requests from other uses "please make
    exported directory configurable" can be included as well.

    Comment (no current need):
    if besides rpc.lockd and rpc.statd you also add rpc.rquotad,
    NFS is complete and prepared for future multiuser-use with
    quotas for disc space.

    On NFS-configuration page or in the manual probably
    following hint is usefull to avoid 'help postings' in the
    forum:

    If yor NFS-client is using file-locking, please make sure
    that FreeNAS can resolve your clients hostname to IP-address
    and vice versa. This requires (at the moment) a running
    DNS-server in your LAN and FreeNAS must be configured to use
    this DNS-server. (later on FreeNAS may hold a /etc/hosts for
    the LAN or even provide a DNS-server itself;-)

    With best regards and awaiting the new release,
    Ingo

     
  • ingo

    ingo - 2006-07-07

    my patched 'services.inc' for NFS-locking

     
  • Olivier Cochard-Labbe

    Logged In: YES
    user_id=1370551

    Hi Ingo,
    thanks a lot's for your help.

    but, because of the need of creating a special directory, I
    will kept your patch for the 0.7 release of FreeNAS (that
    will permit to create more than one share, and begin to
    include user/group permission.)

     
  • SourceForge Robot

    Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • Ingo

    Ingo - 2008-01-09

    Logged In: YES
    user_id=1863902
    Originator: NO

    Today I received a message that this bug was closed.
    I was not aware that this happens automatically after a while when the report was set to pending.

    So assuming that it is not yet fixed I kindly ask to reopen it again. It is really important for me to solve this issue, as I will not update to newer releases of FreeNAS, because then all my workaround gets lost and I have to apply it again.

    With best regards,
    Ingo

     
  • Olivier Cochard-Labbe

    Logged In: YES
    user_id=1370551
    Originator: NO

    Re-open the bug: Still existing

     
  • Ingo

    Ingo - 2008-03-10

    Logged In: YES
    user_id=1863902
    Originator: NO

    For those who really need NFS:

    I did try latest stable 0.686.2 in a VM under VBox. The NFS-Server is incomplete, the 'nlockmgr' has been removed from services. Presumably it is just to avoid this bug of locking the root-directory of a disk (freezes FreeNAS).

    So I personally have to stay with 0.671 and the patch discussed here in the forum to modify the exported directory.
    I am really waiting for 0.7 release, where this is supposed to be solved.

    Best regards,
    Ingo

     
  • Ingo

    Ingo - 2008-03-11

    Logged In: YES
    user_id=1863902
    Originator: NO

    I have to correct some information regarding my previous posting (FreeNAS 0.686.2):

    'nlockmgr' is started by FreeNAS during boot. However it dies silently at the first attempt to mount an export.
    This does not harm for Linux guests - they also mount and allow read/write without locking.
    OS/2 is very sensitive and refuses mounting if it cannot lock.
    Don't know about the Redmond-guests.

    Ingo

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.