[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Also having NFSv4 problems

Robert P. J. Day wrote:
> On Mon, 4 Jan 2010, Robert G. (Doc) Savage wrote:
>> On Sun, 2010-01-03 at 22:05 -0500, Robert P. J. Day wrote:
>>> On Sun, 3 Jan 2010, Robert G. (Doc) Savage wrote:
>>> ... snip ...
>>>> The problem appears to be on the F12 client side:
>>>> # service nfs restart
>>>> Shutting down NFS mountd:                                  [FAILED]
>>>> Shutting down NFS daemon:                                  [  OK  ]
>>>> Shutting down NFS quotas:                                  [  OK  ]
>>>> Shutting down NFS services:                                [FAILED]
>>>> Starting NFS services:                                     [  OK  ]
>>>> Starting NFS quotas:                                       [  OK  ]
>>>> Starting NFS daemon:                                       [  OK  ]
>>>> Starting NFS mountd: Usage: rpc.mountd [-F|--foreground] [-h|--help] [-v|--version] [
>>>> -d kind|--debug kind]
>>>>         [-o num|--descriptors num] [-f exports-file|--exports-file=file]
>>>>         [-p|--port port] [-V version|--nfs-version version]
>>>>         [-N version|--no-nfs-version version] [-n|--no-tcp]
>>>>         [-H ha-callout-prog] [-s|--state-directory-path path]
>>>>         [-g|--manage-gids] [-t num|--num-threads=num]
>>>>                                                            [FAILED]
>>>> About four years ago I was able to set up a similar arrangement
>>>> using nfs3 on RHEL4 and F6, but this is my first attempt with nfs4.
>>>> I seem to be having the same problem Robert P.J. Day is having with
>>>> rpc.mountd.
>>>   a private emailer tells me that what's causing the problem above is
>>> deselecting the NFSv1 line from /etc/sysconfig/nfs.  apparently, that
>>> causes the problem so you should try this:
>>> #MOUNTD_NFS_V1="no"
>>> MOUNTD_NFS_V2="no"
>>> MOUNTD_NFS_V3="no"
>>> weirdly, that fixes that last problem.  why should that be?
>> Robert,
>> Weird is right. It does fix the nfs restart problem, but not the
>> manual nfs mount problem. There's something else still lurking.
>> Thanks.
>   i'll start with submitting the above rpc.mountd error(?) to
> bugzilla.  it seems pretty clear that *needing* NFSv1 support simply
> to *start* rpc.mountd makes no sense.  but there's still another issue
> related to this.
>   as i read it, NFSv4 now incorporates the mount operation in the
> protocol, and i read that as saying that you don't even *need* a
> running rpc.mountd anymore if you restrict yourself to NFSv4.
> however, the earlier emailer wrote the following:
> "My understanding is that mountd, statd etc are still needed but they
> do not need to be exposed to the outside world. That is, you can limit
> all of them in /etc/hosts.allow to and only open port 2049
> on the firewall."
>   so does anyone know for sure?  in any event, i'll bugzilla that
> earlier error.
> rday
> --
> ========================================================================
> Robert P. J. Day                               Waterloo, Ontario, CANADA
>             Linux Consulting, Training and Kernel Pedantry.
> Web page:                                          http://crashcourse.ca
> Twitter:                                       http://twitter.com/rpjday
> ========================================================================


|rpc.mountd| — This process receives mount requests from NFS clients and
verifies the requested file system is currently exported. This process
is started automatically by the |nfs| service and does not require user
configuration. This is not used with NFSv4.

Chihuahuas drive me crazy. I can't stand anything that shivers when it's
warm. Guess Who! http://tinyurl.com/mc4xe7

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]