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

Re: bad nfs mounting



More below.

On Tue, May 24, 2011 at 09:00:51PM -0400, Felix Miata wrote:
> On 2011/05/25 01:40 (GMT+0200) Klaus Knopper composed:
> 
> Thanks for response, and Bernd too!
> 
> >Felix Miata wrote:
> 
> >> # uname -a
> >> Linux Knoppix 2.6.24.4 #2 SMP PREEMPT... (aka 5.3.1)
> 
> >> # portmap
> >> #
> 
> >> # mount -t nfs 192.168.1.2 /nfsmnt
> >> mount.nfs: rpc.statd is not running but is required for remote locking
> >> 	Either use '-o nolocks' to keep locks local, or start statd.
> 
> >"nolocks" does not exist as an option. Are you sure you have read
> >exactly this as error message?
> 
> Yes. Today was not my first encounter with this, only the first I
> took the trouble to mention here.
> 
> >The correct option is "-o nolock", it tells mount not to check for
> >statd/lockd before doing the mount().
> 
> After your reply, I tried again. "nolocks" is the error message,
> while nolock does work.
> 
> >> # mount -t nfs -o nolocks 192.168.1.2 /nfsmnt
> >> mount.nfs: Unsupported nfs mount option: nolocks
> 
> >Should be: mount -t nfs -o nolock 192.168.1.2:/exported_directoryname /nfsmnt
> 
> If I knew how to get busybox to dump command history to a file, like
> bash does to .bash_history, email typos like this would be a smaller
> problem. ;-)
> 
> >> # ls -l /etc/init.d | grep rpc
> >> #
> 
> >There is no lockd/statd running because we need none.
> 
> I just remember once upon a time portmap was good enough by itself,
> and have no idea why every distro switched to using rpc instead.

portmap just reports and allocates ports for rpc services, it does not
do much IO-related by itself.

If programs attempt to lock files and let other programs know about it,
you need a status daemon like lockd or statd that reporte the fact that
a file is locked. OpenOffice/LibreOffice, for example, needs this
feature in order to tell users that someone else ie working on the same
file. It should still be able to edit a file without that feature,
though.

> >> I looked for clues in /etc/init.d/nfs-common and
> >> /etc/init.d/mountnfs.sh for clues how rpc.statd is supposed to get
> >> started, but couldn't recognize any. Why does mount.nfs tell me to
> >> try an option that it cannot recognize? It used to be that all I had
> 
> >Again, I have never seen an error message that told me to use "nolocks",
> >it shoule be "nolock".
> 
> Indeed. I tried 6.4.4 again, using nomodeset on cmdline this time to
> avoid black screens, and the message was indeed nolock instead of
> nolocks.

I thought so. :-)

> >> to remember to mount nfs running Knoppix was to start portmap.
> >> What's the current 5.3.1 secret to accessing nfs? Is it the same in
> >> all versions 5.3.1 or newer?
> 
> >Please have a look into /init, where all the NFS-related mounts for
> >Knoppix terminalserver mode are.
> 
> I'm booted to 6.4.4 now:
> 
> # cd /init
> bash: cd: /init: Not a directory

/init is the initial script run from the initramfs on boot, it is not a
directory. You can read the file by "leafpad /init" or "nano /init".

> >For Knoppix 5.x, you may need "nfsmount" instead of busybox "mount", but
> >for the current 6.4.x version, you can use mount -o nolock.
> 
> With 6.4.4's correct error message, I'm first reminded of rpc.statd,
> so I suppose that might be the better choice than -o nolock?

Depends on what you plan to do. In a single user environment, file
locking is probably unnecessary. For the terminal server feature, it is
easier for me to use nolock than to start additional services from the
ramdisk in order to do locking where I don't really need it.

> Now if I could only remember to always put no3d on cmdline. :-(

When creating a bootable Knoppix USB flash disk, just add your favourite
boot options to boot/syslinux/syslinux.cfg in the APPEND lines. That
way, you won't have to remember typeing them on each boot.

Regards
-Klaus


Reply to: