nfs client does not find nfs server
bastian
both computer suse 10.1,
nfs server installed but client can not find the server.
What might be the reason?
Ping is working fine.
At the beginning I used used YAST to install the nfs server and
checked afterwards manually if everything is running and alright.
Thank you
Bastian
Ian Northeast
> Hello,
> both computer suse 10.1,
> nfs server installed but client can not find the server. What might be the
> reason?
> Ping is working fine.
What exactly do you mean by "cannot find the server"? What is the error
message when you attempt the mount?
"Cannot find the server" would seem to mean a name resolution failure but
if this were so ping wouldn't work either.
Regards, Ian
bastian
> "Cannot find the server" would seem to mean a name resolution failure but
> if this were so ping wouldn't work either.
Ian,
Time out.
I have read in the meantime that something regarding the firewall is
not functioning the way it should.
Regards
Bastian
>
> Regards, Ian
Ian Northeast
>
>> "Cannot find the server" would seem to mean a name resolution failure
>> but if this were so ping wouldn't work either.
>
> Ian,
> Time out.
> I have read in the meantime that something regarding the firewall is not
> functioning the way it should.
That's different. You can tell if it's a firewall problem by comparing the
output of:
rpcinfo -p on the server
rpcinfo -p <server> on the client
They should look the same.
Normally you wouldn't have a firewall between an NFS server and its
client(s). While NFS itself uses a predictable port number (2049), as
does RPC (111), some other components do not, so you don't know in advance
what ports to open. NFS isn't secure anyway (there are enhancements in V4
but it's still not that good). NFS is designed to be used within a LAN
type environment where the other machines are reasonably trustworthy and
no firewall is required between them.
I suggest that you open your firewalls on both client and
server so that all traffic between them is permitted. If this is not
acceptable, you should consider whether NFS is the correct solution to
your data sharing requirement.
Regards, Ian
bastian
I see.
>
> rpcinfo -p on the server
> rpcinfo -p <server> on the client
They look the same.
I can find the server now using YAST after deactivating the firewalls
of both computers.
Nontheless I still have a problem:
server:/etc # mount -t nfs linuxserver.site:/ /linuxserver/
mount server reported tcp not available, falling back to udp
mount: RPC: Fehler des entfernten Systems - Keine Route zum
Zielrechner
Well last words are in German meaning:
mount: RPC: Mistake of the remote system - no route to the computer of
destination
server:/etc # rpcinfo -p
Program Vers Proto Port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100024 1 udp 32770 status
100021 1 udp 32770 nlockmgr
100021 3 udp 32770 nlockmgr
100021 4 udp 32770 nlockmgr
100024 1 tcp 45631 status
100021 1 tcp 45631 nlockmgr
100021 3 tcp 45631 nlockmgr
100021 4 tcp 45631 nlockmgr
100005 1 udp 675 mountd
100005 1 tcp 676 mountd
100005 2 udp 675 mountd
100005 2 tcp 676 mountd
100005 3 udp 675 mountd
100005 3 tcp 676 mountd
I have doubts about the nlockmgr and I wonder whether this is good or
bad?
This is my hosts
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
# On small systems, this file can be used instead of a
# "named" name server.
# Syntax:
#
# IP-Address Full-Qualified-Hostname Short-Hostname
#
127.0.0.1 localhost
# special IPv6 addresses
::1 localhost ipv6-localhost ipv6-loopback
fe00::0 ipv6-localnet
ff00::0 ipv6-mcastprefix
ff02::1 ipv6-allnodes
ff02::2 ipv6-allrouters
ff02::3 ipv6-allhosts
127.0.0.2 server.site server
192.168.0.126 server.site server
192.168.0.134 linuxserver.site linuxserver
And hosts.allow is:
portmap: 192.168.0.134
Bastian
Mark Hobley
> mount: RPC: Mistake of the remote system - no route to the computer of
> destination
> 192.168.0.126 server.site server
> 192.168.0.134 linuxserver.site linuxserver
Confusing names, "linuxserver" is your NFS server, and "server" is your NFS
client. Is that right?
I would give the machines user friendly names, such as scoopy,shaggy,daphny,
etc, and maybe stick a sticker on the front showing the machine name.
> And hosts.allow is:
> portmap: 192.168.0.134
On the server, the address should be that of the client:
portmap: 192.168.0.126
lockd: 192.168.0.126
mountd: 192.168.0.126
rquotad: 192.168.0.126
statd: 192.168.0.126
On the server, cat /etc/exports
Post the output here
To share with any client on the local area network, this should read something
like:
/var/share/sharefolderfoo 192.168.0.0/255.255.255.0(rw)
On the client:
mount linuxserver://var/share/sharefolderfoo /var/share/sharefolderfoo
I hope this helps.
Mark.
--
Mark Hobley
393 Quinton Road West
QUINTON
Birmingham
B32 1QE
Telephone: (0121) 247 1596
International: 0044 121 247 1596
Email: markhobley at hotpop dot donottypethisbit com
bastian
many thanks
nfs is working fine.
I can only export directories. How can I export the whole harddisk
hda. My aim is to make a copy of hda with dd over the network. I just
tried to export /dev/. The root of the nfs client does not have the
necessary rights. So I have to change the rights. Well this is my
status quo at the moment.
>
> Confusing names, "linuxserver" is your NFS server, and "server" is your NFS
> client. Is that right?
yes correct.
> I would give the machines user friendly names, such as scoopy,shaggy,daphny,
> etc, and maybe stick a sticker on the front showing the machine name.
ok.
> On the server, cat /etc/exports
> Post the output here
/ 192.168.0.126(ro,root_squash,sync)
Well I have tried
/dev 192.168.0.126(ro,root_squash,sync)
/dev/hda 192.168.0.126(ro,root_squash,sync)
also.
>
> I hope this helps.
Definitely.
Bastian
bastian
> / 192.168.0.126(ro,no_root_squash,sync)
>
seems to be a solution.
Bastian
Mark Hobley
> / 192.168.0.126(ro,no_root_squash,sync)
> seems to be a solution.
Indeed, root is squashed (mapped to user nobody) by default.
Regards,
bastian
> > seems to be a solution.
>
> Indeed, root is squashed (mapped to user nobody) by default.
unfortunately no_root_squashing is not enough.
I have no access onto /linuxserver/dev/hda.
Bastian
Mark Hobley
On the server, /etc/exports:
/ 192.168.0.0(no_root_squash)
On the client:
# mkdir /media/serverhda
# mount linuxserver:// /media/serverhda
Do you have access to all the server files in /media/serverhda ?
Unruh
>Mark,
Unfortunately this posting is useless is encouraging anyone else tomake
suggestions. There is no information as to what the problem is. Now you may
want us to search back through this thread to figure out what your problem
was. I at least will not. Sorry.
bastian
> On the server, /etc/exports:
>
> / 192.168.0.0(no_root_squash)
OK.
Old version:
/ 192.168.0.126(ro,root_squash,sync)
and now new version:
/ 192.168.0.0(rw,root_squash)
>
> On the client:
>
> # mkdir /media/serverhda
> # mount linuxserver:// /media/serverhda
>
> Do you have access to all the server files in /media/serverhda ?
Yes
server:/media # mount linuxserver:// /media/serverhda/
server:/media # cd serverhda/
server:/media/serverhda # ls
bin dev .gnupg lib mnt proc sbin srv sys usr
windows
boot etc home media opt root server subdomain tmp var
server:/media/serverhda #
Bastian
Ian Northeast
> Hello,
> many thanks
> nfs is working fine.
>
> I can only export directories. How can I export the whole harddisk hda. My
> aim is to make a copy of hda with dd over the network. I just tried to
> export /dev/. The root of the nfs client does not have the necessary
> rights. So I have to change the rights. Well this is my status quo at the
> moment.
You can't export a whole disk. NFS is for filesystems.
You could do what you say you want to do with something like "dd
if=/dev/hda | ssh <remote machine> "cat > somefile" (note the quotes to
prevent the redirection being interpreted locally) but I don't see what it
would achieve. If you want to make a backup then it wouldn't be valid
unless every filesystem on the disk was unmounted and even then it could
be a problem to restore it.
Regards, Ian
bastian
thanks again.
>
> You could do what you say you want to do with something like "dd
> if=/dev/hda | ssh <remote machine> "cat > somefile" (note the quotes to
> prevent the redirection being interpreted locally)
Ok I read about this somewhere else.
but I don't see what it
> would achieve. If you want to make a backup then it wouldn't be valid
> unless every filesystem on the disk was unmounted and even then it could
> be a problem to restore it.
Well I am more optimistic regarding this.
If I dd the whole harddisk
dd if=/dev/hda of=/baks/hda.img bs=6400K
and restore it, it has worked very fine so far.
Have I only been very lucky?
So you recommend me to look for some different backup solution?
Thanks
Bastian
David Brown
If you want a good harddisk based backup system, look at
http://www.dirvish.org/ . It's basically rsync with hardlinked copies
so that you can have multiple regular snapshots without taking up
excessive disk space. Since the snapshot is a complete copy of the tree
in question, you can restore individual files or the complete system by
simple file copy.
bastian
> If you want a good harddisk based backup system, look athttp://www.dirvish.org/. It's basically rsync with hardlinked copies
> so that you can have multiple regular snapshots without taking up
> excessive disk space.
Thank you very much for the hint. I did not know of this.
Unfortunately I have to backup a FAT and NTFS partition too.
As hard linking is required, a traditional UNIX filesystem is a must.
Well it will not help me then I guess.
Bastian
David Brown
There is no problem backing up FAT or NTFS file systems - it is only the
drive you use to store the backups that needs hard link support. I use
dirvish for ext2, reiserfs, fat and ntfs, with the backups all stored on
reiserfs on lvm partitions (the great thing about lvm and reiserfs is
that if I need more space for a partition, I can use lvm to add more
space and then grow the reiserfs filesystem without even unmounting - as
long as I don't have to add another hard disk to the setup, increasing
the partition is a thirty second job).
mvh.,
David
bastian
thank you very much for the clarification of my misunderstanding and
the explanation of the LVM reiserfs combination.
I will retake a closer look at dirvish now.
Bastian
David Brown
It's a combination that has worked well for me, so I like to evangelise
it. The www.dirvish.org website is worth a look, for the various
helpful scripts.
mvh.,
David
bastian
unfortunately copssh nor cwrsync does not work on my windows 2000
professional at all so far. I have tried so many things I can hardly
tell and explain to you. Therefore my start with a new fresh
installation now. What exactly have you done regarding to make this
work.
The aim is to back up a windows client 2000 with a suse linux dirvish
server.
My current system is:
I have a fresh installed version of cwRsync version 2.0.10 on the
windows client again. I have chosen the openssh server additionally
while installing cwRsync, then started the openssh and cwRsync
services and set both onto automatic start.
What do I do next now and how?
I assume I have to activate a user cause if I start putty and try to
acces via ssh and try to login as SvcwRsync with the correct password
the access is denied.
linuxserver under Suse Linux 10.1
IP is 192.168.0.134
client under windows 2000 sp4
IP is 192.168.0.129
Only cwRsync installed on the client not any copSSh or hardbackup at
the moment.
Thanks in advance
Bastian
David Brown
versions work perfectly well - if you want to use unixy programs on
windows it is often the easiest way).
Share the drive or folder you want backed up on the windows machine.
Read-only permission for a single restricted user is fine. On the linux
machine, mount that share and use dirvish to back up the mounted share
(there are some example scripts on the dirvish website for automatically
mounting and umounting before and after the backup). Thus rsync only
runs locally.
If you are backing up huge volumes of data, or using a slow network
(such as off-site backups), then you want to use rsync on the dirvish
computer, with rsyncd (and sshd for security) on the client computer.
But for local net backups, run during the night, it is much easier to
use smb mounts (I use smb mounts to backup the windows clients to a
linux machine, and use an off-site linux machine to back up the backups).
mvh.,
David
bastian
thank you again.
>
> Share the drive or folder you want backed up on the windows machine.
> Read-only permission for a single restricted user is fine. On the linux
> machine, mount that share and use dirvish to back up the mounted share
> (there are some example scripts on the dirvish website for automatically
> mounting and umounting before and after the backup). Thus rsync only
> runs locally.
Sounds like a much more easier solution.
>
> If you are backing up huge volumes of data, or using a slow network
> (such as off-site backups), then you want to use rsync on the dirvish
> computer, with rsyncd (and sshd for security) on the client computer.
> But for local net backups, run during the night, it is much easier to
> use smb mounts (I use smb mounts to backup the windows clients to a
> linux machine, and use an off-site linux machine to back up the backups).
>
Similar to my network.
Bastian
Mark Hobley
> Share the drive or folder you want backed up on the windows machine.
> Read-only permission for a single restricted user is fine. On the linux
> machine, mount that share and use dirvish to back up the mounted share
I tend to open a share on the Linux server, and let Microsoft Windows connect
and write its data, rather than using Microsoft Windows as a server. I then
backup the fileserver in the normal manner.
> If you are backing up huge volumes of data, or using a slow network
> (such as off-site backups), then you want to use rsync on the dirvish
> computer, with rsyncd (and sshd for security) on the client computer.
To backup the Microsoft Windows operating system files, I dual boot the
machine using Linux, then mount the root directory of the Microsoft Windows
partition, and tar off the contents across the network, or to a locally
writable diskette.
(With live cds, this is easy to do, since you can just insert a Linux live cd
disk, into the cdrom drive of the Microsoft Windows machine and reboot before
running using tar to backup the files.)
http://markhobley.yi.org/linux/howto/xpbackup.html
Regards,
David Brown
> David Brown <david...@hesbynett.removethisbit.no> wrote:
>
>> Share the drive or folder you want backed up on the windows machine.
>> Read-only permission for a single restricted user is fine. On the linux
>> machine, mount that share and use dirvish to back up the mounted share
>
> I tend to open a share on the Linux server, and let Microsoft Windows connect
> and write its data, rather than using Microsoft Windows as a server. I then
> backup the fileserver in the normal manner.
>
Do you mean you use the Linux machine as the file server for general use
(which is, of course, the sensible thing to do for most files), or do
you mean you copy on to the Linux machine only when doing backups? If
it's the latter, it sounds less efficient (you must copy more data over
the network), and harder to automate.
>> If you are backing up huge volumes of data, or using a slow network
>> (such as off-site backups), then you want to use rsync on the dirvish
>> computer, with rsyncd (and sshd for security) on the client computer.
>
> To backup the Microsoft Windows operating system files, I dual boot the
> machine using Linux, then mount the root directory of the Microsoft Windows
> partition, and tar off the contents across the network, or to a locally
> writable diskette.
>
Again, I'd look at sharing the partition on the windows machine in some
way. It should be perfectly practical to use dirvish-style backup of a
complete windows machine by booting the machine in linux, mounting the
windows partion(s), and using dirvish (or plain rsync) to get a complete
copy of the machine while only transferring the files needed.
There are three things to keep in mind about backups. One is
reliability of your backups - CD's decay over time, as do tapes,
diskettes of various types, and hard disks (although not much if they
are not powered up). For long term storage, files need re-copying
occasionally. And don't keep your backups in the same building as the
originals!
The second thing to think about is ease of doing the backups. Any
system that relies on people manually copying over files, rebooting
their machines with a live CD, swapping tapes or drives, or long backup
times is going to be hard to keep routine. I've been there and done
that - a tape based backup that ran every few months rather than every
week, simply because no one remembered or bothered to swap the tapes.
Ideally, backups run automatically without user intervention.
The third thing is restoring the data. This is a key point that is
often forgotten - if you have a disaster and need to restore data, can
you easily do it? If it involves a traditional tape backup, you have a
long job ahead to restore a full backup, then a set of incremental or
differential backups, and it's a serious effort if all you want is a
couple of files that some twit accidentally deleted. Similarly, a
complete backup of a Windows system with all its OS files is virtually
useless unless it is a pure disk image - you have no way to restore it.
A big advantage of dirvish is that the data is available as a normal
file system tree - restore is a matter of copying over as much or as
little data as desired.
mvh.,
David
Mark Hobley
>
> Do you mean you use the Linux machine as the file server for general use
> (which is, of course, the sensible thing to do for most files), or do
> you mean you copy on to the Linux machine only when doing backups?
I mean use the Linux machine for general use. (Microsoft Windows based servers
are in my experience unreliable).
> There are three things to keep in mind about backups. One is
> reliability of your backups - CD's decay over time, as do tapes,
> diskettes of various types, and hard disks (although not much if they
> are not powered up). For long term storage, files need re-copying
> occasionally. And don't keep your backups in the same building as the
> originals!
Take two backups, if it is for long term storage. I like laser servo diskettes,
but unfortunately they are obsolete now. I still use them here though.
> The second thing to think about is ease of doing the backups. Any
> system that relies on people manually copying over files, rebooting
> their machines with a live CD, swapping tapes or drives, or long backup
> times is going to be hard to keep routine.
It may be worth fitting a removable hard drive caddy, or backing up onto a USB
drive. Remove the drive when the backup is complete.
> The third thing is restoring the data. This is a key point that is
> often forgotten - if you have a disaster and need to restore data, can
> you easily do it?
A full backup on a big hard drive is easy to restore.
bastian
how have you configured dirvish in a way not asking for the password.
At step 2. and 3. dirvish keeps on asking me for a password.
1.
linuxserver:/ # smbmount //client/AGFEO /mnt -o
username=tc2backup,password=xxxx
linuxserver:/ #
2.
linuxserver:/var/baks # /usr/local/sbin/dirvish -vault client -init
Password:
linuxserver:/var/baks #
3.
linuxserver:/var/baks # /usr/local/sbin/dirvish-runall
14:55:28 /usr/local/sbin/dirvish --vault client
Password:
14:55:32 done
linuxserver:/var/baks #
Thanks
Bastian
bastian
http://wiki.dirvish.org/?SmbMount
Now I know what you mean I guess.
I will take a closer look
Bastian
bastian
can you please post or send me
bastian <basti...@postdienst.net>
an example of your master.conf and default.conf which you use to back
up the exported folders of a windows 2000 client via SMB.
I could not make it run in the past couple of hours using the scripts
at
http://wiki.dirvish.org/?SmbMount
I have tried various things:
My current master.conf in /etc/dirvish/ is:
bank:
/var/baks
client: localhost
log: none
tree: /mnt/dirvish/client/
Dirvish: /usr/local/sbin/dirvish
index: none
pre-server: /usr/local/bin/mount-win-share client
username=tc2backup password=xxxx ip=192.168.0.129
Runall:
client
post-server: /usr/local/bin/umount-win-share client
My current default.conf in /var/baks/client/dirvish is:
client: 192.168.0.134
tree: /mnt/dirvish/client/
The error I get:
linuxserver:/var/baks # /usr/local/sbin/dirvish -vault data -init
cannot open config file: default.conf
By the way:
Backing up Windows machines using smbclient
You can use the pre-server and post-server options in your
dirvish.conf to
mount and umount Windows shares. Your c:\ folder must be exported (as
read
only, of course).
client: localhost
tree: /mnt/dirvish/<mymachinename>/
pre-server: /usr/local/bin/mount-win-share <mymachinename>
username=<myuser> password=<mypass> ip=mymachinenameorip
post-server: /usr/local/bin/umount-win-share <mymachinename>
The password option is just an example. You are better off using
password
files, etc.
my question:
What is <mymachinename>? The Windows client named client I guess in my
case?
So I replace <mymachinename> by the word client? Correct?
The <myuser> is the windows 2000 user who has read only access onto
the
exported folde c:\?
Thank you
Bastian
David Brown
I think your problem here is that the "vault" option should correspond
to the directory in the bank. Thus you should either run dirvish with
"--vault client" (to dashes, by the way), or change the directory name
to "/var/baks/data/".
Secondly, the client in default.conf should be the localhost (or its IP
address).
You should not specify "client", "tree", "pre-server" or "post-server"
in master.conf, but in the default.conf file for each tree you are storing.
>
> By the way:
> Backing up Windows machines using smbclient
>
> You can use the pre-server and post-server options in your
> dirvish.conf to
> mount and umount Windows shares. Your c:\ folder must be exported (as
> read
> only, of course).
>
> client: localhost
> tree: /mnt/dirvish/<mymachinename>/
> pre-server: /usr/local/bin/mount-win-share <mymachinename>
> username=<myuser> password=<mypass> ip=mymachinenameorip
> post-server: /usr/local/bin/umount-win-share <mymachinename>
>
> The password option is just an example. You are better off using
> password
> files, etc.
>
I don't know details of the "mount-win-share" script - did it come from
the dirvish website? If so, there might be information there.
I'd suggest that you first manually make the directory
/mnt/dirvish/<mymachinename>, and mount the windows share on it. Once
you see that it's working, you can do your first backup, then umount it.
Making the mount/umount automatic should be step two.
>
> my question:
> What is <mymachinename>? The Windows client named client I guess in my
> case?
> So I replace <mymachinename> by the word client? Correct?
> The <myuser> is the windows 2000 user who has read only access onto
> the
> exported folde c:\?
>
That all sounds about right, but I am not familiar with the
mount-win-share script (having written my own single-line script for the
purpose). Try it out manually first, and see if you can read the
mounted drive.
mvh.,
David
> Thank you
> Bastian
>