Solved NFS problem again

Greetings all,

after rebuilding my server, the NFS does not work again. I have configured both the server and the client as per the previously working configuration, but showmount -e server_IP results in
Code:
PRC: Program not registered
showmount: can't do exports rpc
Trying to restart mountd(8), which I understand could cause the problem results in:
Code:
/etc/rc.d/mountd: WARNING: /etc/exports is not readable
/etc/rc.d/mountd: WARNING: failed pecmd routine for mountd
Of course /etc/exports is not readable since it does not exist. But (i) this configuration worked before and (ii) according to previously cited article https://klarasystems.com/articles/nfs-shares-with-zfs/, OpenZFS v. 2.1 reads the parameters for mounting from /etc/zfs/exports, which exists and is correctly configured by the zfs sharenfs command.

So, what is the solution? Using the /et/exports? In that regard, I note that the zfs(8) for 13.1-RELEASE, does not have the hack(?) of the previous 12.3-RELEASE:
A file system with a sharenfs property of off is managed
the traditional way via exports(5). Otherwise, the file system is
automatically shared and unshared with the "zfs share" and "zfs
unshare" commands.
and even this implies that the manner described in the above-cited article is preferable.

Kindest regards,

M
 
after rebuilding my server, the NFS does not work again. I have configured both the server and the client as per the previously working configuration,
Please post from NFS server uname -miro, grep nfs /etc/rc.conf, if existent and has any content cat /etc/exports and zfs get sharenfs.

From the NFS client uname -miro, grep nfs /etc/rc.conf, eventually the executed mount command.

If you consider some of the output to sensitive for public viewing, redact that part.

but showmount -e server_IP results in
Code:
PRC: Program not registered
showmount: can't do exports rpc
Can you ping(8) the NFS servers IP?

Trying to restart mountd(8), which I understand could cause the problem results in:
Code:
/etc/rc.d/mountd: WARNING: /etc/exports is not readable
/etc/rc.d/mountd: WARNING: failed pecmd routine for mountd
Of course /etc/exports is not readable since it does not exist.
On a NFSv3 ZFS NFS mount a /etc/exports is not absolutely necessary. mountd(8) will complain, but this doesn't affect the mount. To silence the mountd(8) log a empty file can be placed.

It's necessary if NFSv4 is intended, a V4: <rootdir> must be specified there.

So, what is the solution?
To answer that, first the root cause must be found. Please post those information's requested at the beginning.

I note that the zfs(8) for 13.1-RELEASE, does not have the hack(?) of the previous 12.3-RELEASE:
A file system with a sharenfs property of off is managed
the traditional way via exports(5). Otherwise, the file system is
automatically shared and unshared with the "zfs share" and "zfs
unshare" commands.
Starting with 13.0 SUN'S ZFS was replaced by OpenZFS. This affected the ZFS manuals. On 12.3 (and prior versions) the zfs(8) manual is a single one, from 13.0 on, each ZFS subcommand has its own manual, man zfs(8) listing those subcommands.

You will find a similar, more detailed, paragraph what you have quoted from 12.3 zfs(8) in the (OpenZFS) manual zfsprops(7), under the "sharenfs" property.



I like to add that the cited Klarasystems article NFS Shares With ZFS has a mistake. In the article it is claimed in "Things to Keep in Mind:"
Don’t forget to prepend your options with on to enable NFS sharing on the specified dataset.

zfs set sharenfs=’on,-maproot=root,192.168.15.0/24’ mypool/usr/ports
It is not required to enable NFS shares by setting the "on" option to the "sharenfs" property. Any valid option set as value for "sharenfs" enables the NFS export.

It's sufficient to set above example as zfs set sharenfs=’maproot=root,192.168.15.0/24’ mypool/usr/ports.
 
Hi T-Daemon,

Thank you for the reply. I actually fixed the problem by # touch /etc/exports and all started to work immediatelly. I still do not understand why, since mountd(8), now that it starts, has no problem finding and using /etc/zfs/exports although it is not directly specified as mountd(8) suggests, cf.
exportsfile
Specify an alternate location for the exports file. More than
one exports file can be specified.
So, why could it not use it upon startup when it had been specified by zfs set sharenfs is a mystery to me.

You will find a similar, more detailed, paragraph what you have quoted from 12.3 zfs(8) in the (OpenZFS) manual zfsprops(7), under the "sharenfs" property.
Aha. I read zfs(8) section zfs-share(8) reciting:
filesystem
Share the specified filesystem according to the sharenfs and
sharesmb properties. File systems are shared when the sharenfs or
sharesmb property is set.
and since I had set zfs set sharenfs, I thought I was done.

It is not required to enable NFS shares by setting the "on" option to the "sharenfs" property. Any valid option set as value for "sharenfs" enables the NFS export.
Correct again. When I was desperately reading through the various man-pages, I found that the "on" is set as a default.

So, all works great on my *BSD machines; I was even able to mount the share on Windows 10 using the built-in NFS client, but surprisingly, I have problem with permissions, so to figure it out is today's task.

Thank you once again for your time.

Kindest regards,

M
 
Hi Jose,

Do I detect sarcasm?
That is a keen observation, and the answer is yes and no.

Yes, because of my previous experience with Windows/*nix interfacing, which was again confirmed. No, because before I attempted the NFS mount, I had read several rather positive reports.

I would really like to solve it, so that I do not have to again run both SMB and NFS.

Kindest regards,

M
 
I actually fixed the problem by # touch /etc/exports and all started to work immediatelly. I still do not understand why, since mountd(8), now that it starts, has no problem finding and using /etc/zfs/exports although it is not directly specified as mountd(8) suggests, cf.

So, why could it not use it upon startup when it had been specified by zfs set sharenfs is a mystery to me.
Without knowing more details about the configuration it's not possible to point at a possible cause.

The most basic NFSv3 configuration (you have touch /etc/exports, that means there is no V4: <rootdir> line for NFSv4 exports) is:

NFS server /etc/rc.conf:
Code:
nfs_server_enable="YES"
zfs set sharenfs=on pool/dataset

On a FreeBSD NFS client, no configuration needed:
mount server:/pool/dataset /mnt
 
Hi T-Daemon,

thank you for your reply.
Without knowing more details about the configuration it's not possible to point at a possible cause.
It is just plain fresh install of 13.1-RELEASE. Or, if you mean the NFS, for now I have more-or-less followed our previous discussion for NFSv3 only because (i) I really wanted to have that working first and (ii) Windows 10 client supports only NFSv2 and v3. And, I would prefer avoiding SMB.

The most basic NFSv3 configuration (you have touch /etc/exports, that means there is no V4: <rootdir> line for NFSv4 exports) is:
That is not, what the Handbook says: https://docs.freebsd.org/en/books/handbook/network-servers/, consequently, I have in the server /etc/rc.conf:
Code:
rpcbind_enable="YES"
nfs_server_enable="YES"
# nfs_v4_server_enable="YES"
mountd_enable="YES"
mountd_flags="-r"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"

As best as I can tell, the mountd(8) will not start without the /etc/exports, regardless of the fact that the /etc/zfs/exports exists.

On a FreeBSD NFS client, no configuration needed:
Id., re the Handbook. As such, I have in the client /etc/rc.conf:
Code:
nfs_client_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"

Kindest regards,

M
 
Hi mefizto,

you already marked the thread as "Solved", I hope you have no objection when I continue to provide some more information regarding the minimal necessary configuring of a NFS on FreeBSD. You expressed in the other thread the need to understand the effect of a command before executing it (in this case configuration settings), and not following it blindly. The following explanation demonstrates why nfs_server_enable is all it needs to configure a NFS(v3) server.

The most basic NFSv3 configuration (you have touch /etc/exports, that means there is no V4: <rootdir> line for NFSv4 exports) is:

NFS server /etc/rc.conf:
Code:
nfs_server_enable="YES"
zfs set sharenfs=on pool/dataset
Unfortunately the Handbook is not up to date with the current state of the systems capability.

consequently, I have in the server /etc/rc.conf:
Code:
rpcbind_enable="YES"
nfs_server_enable="YES"
# nfs_v4_server_enable="YES"
mountd_enable="YES"
mountd_flags="-r"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
rpcbind, mountd and eventually mountd_flags are not necessary.

Those variables in /etc/rc.conf are On/Off (YES, NO), and other configuration parameter knobs for rc.d (8)scripts under /etc/rc.d (if scripts from packages/ports then also from /usr/local/etc/rc.d).

Many of the /etc/rc.d scripts need other scripts to run before or after running themself. Those are specified in the scripts REQUIRE and BEFORE rcorder(8) keywords. When REQUIRE, all specified scripts (so called "conditions") in that line are started before the script itself is started.

After the above explanation it will be clearer why rpcbind, mountd and eventually mountd_flags variables are unnecessary.

mountd_enable="YES" doesn't need to be set, nfs_server_enable="YES" calls /etc/rc.d/nfsd, which starts /etc/rc.d/mountd automatically (# REQUIRE: mountcritremote mountd hostname gssd nfsuserd)

mountd_flags="-r": The default is set as mountd_flags="-r -S" in /etc/defaults/rc.conf, set it if you want to override the default setting "-r -S". (See also ps aux below.)

rpcbind_enable="YES" doesn't need to be set either. /etc/rc.d/nfsd starts /etc/rc.d/mountd, which starts /etc/rc.d/rpcbind (/etc/rc.d/mountd, # REQUIRE: NETWORKING rpcbind quota).

To proof the above in a live system, checked in a nfs_server_enable="YES" only, no /etc/exports, ZFS sharenfs exported NFS server:
Code:
# ps aux | egrep 'nfsd|mountd|rpcbind'
root  722   0.0  0.6 12836 2612  -  Ss   09:37     0:00.01 /usr/sbin/rpcbind
root  743   0.0  0.6 12892 2680  -  Ss   09:37     0:00.57 /usr/sbin/mountd -r -S /etc/exports  /etc/zfs/exports
root  745   0.0  0.5 12764 2532  -  Is   09:37     0:00.03 nfsd: master (nfsd)
root  748   0.0  0.6 12764 2708  -  S    09:37     0:00.01 nfsd: server (nfsd)
root  979   0.0  0.5 12848 2412 v4  S+   10:05     0:00.00 egrep nfsd|mountd|rpcbind

The details of the above REQUIRE and other rcorder(8) keywords can be looked in the just mentioned manual, rc(8), rc.subr(8), Practical rc.d scripting in BSD.

To configure a NFSv4 FreeBSD server all is needed is to set
Code:
nfs_server_enable="YES"
nfsv4_server_enable="YES"

eventually

nfsuserd_enable="YES"
nfsv4(4)

On a FreeBSD NFS client, no configuration needed:
Id., re the Handbook. As such, I have in the client /etc/rc.conf:
Code:
nfs_client_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
Try to mount on the client without any rc.conf configuration.

As best as I can tell, the mountd(8) will not start without the /etc/exports, regardless of the fact that the /etc/zfs/exports exists.
mountd(8) will start, regardless if /etc/exports exist. At most it will complain about the missing file in the logs.

I don't see why your setup wouldn't work without a (empty) exports file, well, the important things is, it's working now.
 
Hi T-Daemon,

Hi [FONT=monospace]mefizto[/FONT],

you already marked the thread as "Solved", I hope you have no objection when I continue to provide some more information regarding the minimal necessary configuring of a NFS on FreeBSD. You expressed in the other thread the need to understand the effect of a command before executing it (in this case configuration settings), and not following it blindly.
Not at all, just the opposite. I actually condensed all (mostly your) explanations into a document that I was referring to when I had trouble with the reconfigured server. In fact, I have a few questions regarding your post, but if/when you get tired of them, cheerfully ignore them.

Those variables in /etc/rc.conf are On/Off (YES, NO), and other configuration parameter knobs for rc.d (8)scripts under /etc/rc.d (if scripts from packages/ports then also from /usr/local/etc/rc.d).

Many of the /etc/rc.d scripts need other scripts to run before or after running themself. Those are specified in the scripts REQUIRE and BEFORE rcorder(8) keywords. When REQUIRE, all specified scripts (so called "conditions") in that line are started before the script itself is started.
That is very interesting. It was my understanding, that the order of the lines in /etc/rc.conf is immaterial, cf. e.g., https://forums.freebsd.org/threads/...an-image-file-to-usb.70933/page-2#post-430065, https://forums.freebsd.org/threads/vlan-not-working.72754/#post-443386.

However, based on your description, this is not entirely correct.

mountd_enable="YES" doesn't need to be set, nfs_server_enable="YES" calls /etc/rc.d/nfsd, which starts /etc/rc.d/mountd automatically (# REQUIRE: mountcritremote mountd hostname gssd nfsuserd)
rpcbind_enable="YES" doesn't need to be set either. /etc/rc.d/nfsd starts /etc/rc.d/mountd, which starts /etc/rc.d/rpcbind (/etc/rc.d/mountd, # REQUIRE: NETWORKING rpcbind quota).
This begs the following question. Since my above-posted /etc/rc.conf has the sequence
rpcbind_enable="YES" - nfs_server_enable="YES" - mountd_enable="YES", which appears to be wrong by your quotes above, how does the system figure the correct sequence out?

mountd(8) will start, regardless if /etc/exports exist. At most it will complain about the missing file in the logs.
If you refer to my first post, mountd(8) did not start until I created an empty /etc/rc.conf. It seems unlikely that I had another mis-configuration because once I created the /etc/rc.conf, all started to work.

I don't see why your setup wouldn't work without a (empty) exports file, . . .
I do not understand it either.

. . . well, the important things is, it's working now.
Yes and no. I prefer to have the simplest configuration as not to over-complicate things and, potentially, introduce inconsistencies. So, I will now further experiment by commenting out the directives you indicated as unnecessary and deleting the /etc/exports.

So, expect "I have another problem" post soon. ;)

Kindest regards,

M
 
Hi T-Daemon,

just wanted to let you know that after I made the above-mentioned changes, everything works, even the mountd(8) starts with the /etc/exports removed, as you suggested.

I understand that NFSv3 does not support UTF-8 encoding. However, since you seem to know everything about NFS, is there any workaround? I understand, that I can use NFSv4 on the *BSD machines, but I would really like to have the NFS mount working on Windows, wherein NFSv4 is not supported. (When I say work, I mean sorting out the permissions, I can mount the share, just do not seem to figure out the permissions to access it).

Kindest regards,

M
 
It was my understanding, that the order of the lines in /etc/rc.conf is immaterial, cf. e.g.,
However, based on your description, this is not entirely correct.
This begs the following question. Since my above-posted /etc/rc.conf has the sequence
rpcbind_enable="YES" - nfs_server_enable="YES" - mountd_enable="YES", which appears to be wrong by your quotes above,
I'm afraid I haven't expressed myself clear enough, which lead to a misunderstanding on your part.

The order of variables (lines) in /etc/rc.conf IS immaterial, you can put them orderless.

What I'm trying to explain was, the variable nfs_server_enable set in /etc/rc.conf will start mountd, and rpcbind nonetheless if they are set as option in /etc/rc.conf or not.

how does the system figure the correct sequence out?
As last stage of the boot process init(8) is called, which executes /etc/rc, a command script for starting up the other scripts with the help of rcorder(8). rcorder(8) determines the order of the scripts and the dependencies between them. In this process /etc/defaults/rc.conf, and /etc/rc.conf are sourced.

In /etc/defaults/rc.conf are default options (variables) for the system configuration defined, in /etc/rc.conf those default options can be overridden and additional options specified, provided by installed ports/packages scripts under /usr/local/etc/rc.d/.

Back to "how does the system figure the correct sequence out?" The system boots, init(8) is calling /etc/rc, rc(8) is calling rcorder(8), options (variables) in /etc/defaults/rc.conf and /etc/rc.conf are sourced, rcorder(8) identifies the dependencies and their correct order from the keywords (those keywords are PROVIDE, REQUIRE, BEFORE, KEYWORD) in the scripts under /etc/rc.d/ (and /usr/local/etc/rc.d/) scripts, at last rc(8) starts all the identified scripts.

To the claim why is it enough to set only nfs_server_enable="YES and not also mountd_enable and rpcbind_enable

Setting nfs_server_enable="YES" will enable the /etc/rc.d/nfsd script, rcorder(8) reads from the script # REQUIRE: mountcritremote mountd hostname gssd nfsuserd, determines the dependencies and rc(8) starts them.

mountd is forced to start as a dependency ( /etc/rc.d/nfsd: force_depend mountd), and rpcbind is forced to start as a dependency from /etc/rc.d/mountd (force_depend rpcbind).

If you refer to my first post, mountd(8) did not start until I created an empty /etc/rc.conf. It seems unlikely that I had another mis-configuration because once I created the /etc/rc.conf, all started to work.
I believe you mean /etc/exports, not /etc/rc.conf. Without a /etc/rc.conf there is no network interface configuration, no NFS sharing.
 
just wanted to let you know that after I made the above-mentioned changes, everything works, even the mountd(8) starts with the /etc/exports removed, as you suggested.
I didn't suggest to remove it, I wanted to explain that /etc/exports is not required to export a ZFS sharenfs enabled NFSv3 share. You can let it there, it will also silence mountd warning messages logging.

I understand that NFSv3 does not support UTF-8 encoding.
Where did you get that notion? If the NFS client doesn't display UTF-8, most likely the clients environment doesn't support UTF-8.

Testing on a NFS server: In the NFSv3 exported directory /nfsshare is a file named "my name is Peter" in Russian (online machine translated).

On a FreeBSD client, in vt(4) which supports UTF-8, the NFSv3 mounted directory displays Russian characters:

Notice nfsv3 from the nfsstat -m printed output.

UTF-8-NFS-client.png

since you seem to know everything about NFS
That is vastly exaggerated. I know my way around in a home network environment.
 
mountd is forced to start as a dependency ( /etc/rc.d/nfsd: force_depend mountd), and rpcbind is forced to start as a dependency from /etc/rc.d/mountd (force_depend rpcbind).
I disapprove of this transitive dependency approach. The force_depend directive should fail noisily if the required dependency is not enabled. Doing magic in the background like this makes the system confusing and hard to troubleshoot.
 
Hi T-Daemon,

thank you for the continuing education.

The order of variables (lines) in /etc/rc.conf IS immaterial, you can put them orderless.

What I'm trying to explain was, the variable nfs_server_enable set in /etc/rc.conf will start mountd, and rpcbind nonetheless if they are set as option in /etc/rc.conf or not.
I understood that. What I was confused abut was the fact that if, e.g., the rpcbind_enable="YES" is listed before the nfs_server_enable="YES", the rpcbind (8)would be started out-of-order. However, your explanation below:

Back to "how does the system figure the correct sequence out?" The system boots, init(8) is calling /etc/rc, rc(8) is calling rcorder(8), options (variables) in /etc/defaults/rc.conf and /etc/rc.conf are sourced, rcorder(8) identifies the dependencies and their correct order from the keywords (those keywords are PROVIDE, REQUIRE, BEFORE, KEYWORD) in the scripts under /etc/rc.d/ (and /usr/local/etc/rc.d/) scripts, at last rc(8) starts all the identified scripts.

I believe you mean /etc/exports, not /etc/rc.conf. Without a /etc/rc.conf there is no network interface configuration, no NFS sharing.
You are, of course, correct, it is now corrected in my post, so as not to confuse potential readers.

I didn't suggest to remove it, I wanted to explain that /etc/exports is not required to export a ZFS sharenfs enabled NFSv3 share.

Well, you wrote:
mountd(8) will start, regardless if /etc/exports exist. At most it will complain about the missing file in the logs.
so, I guess it is rather ambiguous. Nevertheless, all works without it.

Where did you get that notion [of no support on NFSv3]?
As I use different languages, I have all encoded with UTF-8. When i mounted the share, the filenames with the non-ASCII characters were garbled. I found the following link https://docs.oracle.com/cd/E56021_01/html/E55851/gokvz.html, which states that the default is pass-through, thus UTF-* should have been passed on the client.

Kindest regards,

M
 
thus UTF-* should have been passed on the client.
That is the case. If the non-ASCII characters are garbled, then the clients current environment and/or the application on the client doesn't support UTF-8.

Which application(s) showing garbled characters is/are in use on the client? What does locale(1) show?

As I use different languages,
Are some or all of them Asiatic? Those require additional configuration.
 
Hi T-Daemon,

thank you, again, for your help.

Which application(s) showing garbled characters is/are in use on the client? What does locale(1) show?
That is the interesting part. When I mount the data-set, let us say on /mnt and examine the data-set with CLI, e.g., ls -als, I can see some of the non-ASCII characters being replaced with, e.g., ,<EX>, the X being a number depending on a character. Hence I concluded, incorrectly, as this might be a shell issue, that the UTF-8 is not supported.

Yesterday I experimented with file managers, and to my surprise Xfe(1) renders certain non-ASCII characters correctly, others are replaced with underscore (same language). PCmanFM garbles all non-ASCII characters.

Code:
LANG=C.UTF-8
LC_CTYPE="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_TIME="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=

Are some or all of them Asiatic? Those require additional configuration.
Nope, Indo-European.

Kindest regards,

M
 
I can't reproduce garbled characters in virtual terminal, or xterminal (x11/rxvt-unicode), or x11-fm/xfe and x11-fm/pcmanfm-qt on 13.1-RELEASE. All UTF-8 Indo-European character are displayed correct.

Maybe the DE or WM you are using sets some localization. Try in a freshly added user, set the login shell to one provided by the base, check in virtual terminal and run those file manager inside a light WM.
 
Back
Top