since I installed a local DNS-server and since
FreeNAS 0.671 (including file locking) everything is
almost perfect!
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
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
my patched 'services.inc' for NFS-locking
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
my patched 'services.inc' for NFS-locking
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.)
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).
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
Logged In: YES
user_id=1370551
Originator: NO
Re-open the bug: Still existing
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
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