Prev: X graphics
Next: Slackware 13 Pkgtools on backlevel systems
From: john on 21 Jun 2010 13:18
Robby Workman wrote:

> On 2010-06-20, john <here(a)home.hams> wrote:
>> I can't mount the two exported nfs directories on my file storage box
>> like I would usually do with prior slackware versions. The nfs-utils on
>> the serverside are vers. 1.0.7. and nfs-utils-1.2.2 on the Slackware
>> 13.1 install. It still mounts the directories on a 13.0 install with no
>> problems. I,m using a simple hosts list in /etc/hosts on all machines.
>> Has anyone one else experienced a problem or do I need to mount the
>> remote directories differently?
>
>
> Try passing "-o vers=3" to the mount command.
>
> -RW

Thank you all for your responses.

Robby Workman,s suggestion fixed it.

Henrik's suggestion produced these:

The 13.0 machine:

root(a)mama-bear:~# cat /proc/filesystems | grep nfs
nodev nfs
root(a)mama-bear:~# ps -auxw | grep rpc.portmap
Warning: bad ps syntax, perhaps a bogus '-'?
bin 3247 0.0 0.0 1896 476 ? Ss 10:55 0:00
/sbin/rpc.portmap
root 3754 0.0 0.0 2204 628 pts/1 R+ 11:02 0:00 grep
rpc.portmap
root(a)mamabear:~# /usr/sbin/showmount -e papa-bear
Export list for papa-bear:
/usr/local/pub *.fakedomain.com
/usr/bigstor *.fakedomain.com
root(a)mama-bear:~#

The 13.1 machine:

root(a)baby-bear:~# cat /proc/filesystems | grep nfs
nodev nfs
nodev nfs4
nodev nfsd
root(a)baby-bear:~# ps -auxw | grep rpc.portmap
Warning: bad ps syntax, perhaps a bogus '-'?
bin 1599 0.0 0.0 1904 488 ? Ss 08:13 0:00
/sbin/rpc.portmap
root 5055 0.0 0.0 2216 676 pts/1 S+ 11:12 0:00 grep
rpc.portmap
root(a)baby-bear:~# /usr/sbin/showmount -e papa-bear
Export list for papa-bear:
/usr/local/pub *.fakedomain.com
/usr/bigstor *.fakedomain.com
root(a)baby-bear:~#

thanks again...
john
From: Henrik Carlqvist on 22 Jun 2010 02:32
john <here(a)home.hams> wrote:

> Robby Workman wrote:
>> Try passing "-o vers=3" to the mount command.

> Robby Workman,s suggestion fixed it.

> root(a)baby-bear:~# cat /proc/filesystems | grep nfs
> nodev nfs
> nodev nfs4
> nodev nfsd

So it seems as if Slackware 13.1 by default uses NFS version 4 which was
not supported at all in your earlier versions of Slackware. If this is the
solution it is also possible to add "vers=3" to the line in /etc/fstab.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root(a)localhost postmaster(a)localhost

From: Chris Vine on 24 Jun 2010 20:22
On Mon, 21 Jun 2010 13:18:16 -0400
john <here(a)home.hams> wrote:
> Robby Workman wrote:
>
> > On 2010-06-20, john <here(a)home.hams> wrote:
> >> I can't mount the two exported nfs directories on my file storage
> >> box like I would usually do with prior slackware versions. The
> >> nfs-utils on the serverside are vers. 1.0.7. and nfs-utils-1.2.2
> >> on the Slackware 13.1 install. It still mounts the directories on
> >> a 13.0 install with no problems. I,m using a simple hosts list
> >> in /etc/hosts on all machines. Has anyone one else experienced a
> >> problem or do I need to mount the remote directories differently?
> >
> >
> > Try passing "-o vers=3" to the mount command.
> >
> > -RW
>
> Thank you all for your responses.
>
> Robby Workman,s suggestion fixed it.

nfs v4 requires either a root (in the sense of root-of-tree) share
specified in exports which contains all other exported shares with
fsid=0, or pseudo root compiled into the kernel. Stock kernels do not
have pseudo root. That was probably your problem. Mind you, I am
surprised that dmesg doesn't alert you to the cause of the problem: it
did to me.

Steer clear of version 4. Without pseudo root, the root file system
will be world readable and a bad idea. Mind you, nfs seems to me to be
a bad idea more generally, so no change there maybe, but if you really
have use nfs rather than a more secure file sharing system, then stick
to version 2/3.

Chris

From: Henrik Carlqvist on 25 Jun 2010 06:07
Chris Vine <chris(a)cvine--nospam--.freeserve.co.uk> wrote:
> Steer clear of version 4.

I have no experience from version 4 myself, but I have also heard that
version 3 is to prefer from other sources.

> Mind you, nfs seems to me to be a bad idea more generally, so no change
> there maybe, but if you really have use nfs rather than a more secure
> file sharing system, then stick to version 2/3.

Do you have any other file sharing system that you would suggest? In my
expericence nfs v3 is the best supported file sharing system in a
Linux/Unix/Posix environment.

Security concerned, with nfs v3 the server has to trust the machines on
the ip adresses of the clients unless you use kerberos which I haven't
tried myself, but it really seems to be a mess.

With smbfs/cifs you don't have to trust the client machines, but you lose
things like symbolic links and device nodes on the shares.

Other file systems like andrewfs seems nice, but no other file system
seems as well integrated with Linux as NFS. They all do require special
userspace servers and will require more to get a working system.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root(a)localhost postmaster(a)localhost

From: Chris Vine on 29 Jun 2010 20:00
On Fri, 25 Jun 2010 12:07:34 +0200
Henrik Carlqvist <Henrik.Carlqvist(a)deadspam.com> wrote:
> Chris Vine <chris(a)cvine--nospam--.freeserve.co.uk> wrote:
> > Steer clear of version 4.
>
> I have no experience from version 4 myself, but I have also heard that
> version 3 is to prefer from other sources.
>
> > Mind you, nfs seems to me to be a bad idea more generally, so no
> > change there maybe, but if you really have use nfs rather than a
> > more secure file sharing system, then stick to version 2/3.
>
> Do you have any other file sharing system that you would suggest? In
> my expericence nfs v3 is the best supported file sharing system in a
> Linux/Unix/Posix environment.

I tend to use sshfs, which is a FUSE file system. It's advantage is
that, unlike with NFS, the user's status is entirely determined by her
log-on credentials on the server, rather than by credentials on the
client machine. Thus, you don't need to rely on things like
root_squash to prevent a user with root access on her own (client)
machine being able to achieve elevated status on the server.

I use sshfs because I have to export some file systems for my use when
I am "on the road", via the public internet, but I have now started
using it more generally within my local network in place of NFS. (NFS
is horrendously insecure on the local network if you try to do port
tunnelling of NFS with ssh to enable it to be mounted via the
internet: by port tunnelling, anyone with ssh login credentials can
obtain root access on the server if they have root access on the
client machine, because root_squash will be ignored.)

sshfs has a reputation of crashing sometimes on heavy load but I have
found the latest version (sshfs-fuse-2.2) works well with the latest
version of fuse, as supplied with slackware-13.1, and has yet to crash
for me.

In case it is of use, in my /etc/fstab file I pass the following
options to sshfs: allow_other,reconnect,noauto,user. You might also
want to use the fsname option so that the device name in mtab matches
the name in /etc/fstab, so enabling the file system to be unmounted by
a user by calling umount (that is, without having to call fusermount
-u). You might also want to look up what the "allow_other" fuse option
does to see if you want it (another possibility is "allow_root").

It should be noted that sshfs does not do file locking (but neither
does NFS if you do tunnelling via ssh), so if one user is writing to a
file while another is reading it, a defective read may take place. But
that is no different from what happens where two users access the same
file contemporaneously locally, without a network file system.

Chris
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: X graphics
Next: Slackware 13 Pkgtools on backlevel systems