Date: Sat, 29 Nov 1997 12:54:50 +0100 From: Volker Paepcke <scratchy@vulcan.franken.de> To: freebsd-questions@freebsd.org Subject: [AMD]: automounting cdroms is working, but... Message-ID: <199711291154.MAA01209@yavin.franken.de>
next in thread | raw e-mail | index | archive | help
Hi!
I know, we had this topic already a few times. But after reviewing all archived
messages about automounting a cdrom, I haven't found any working
solution for this (at the first glance) simple scenario:
1.) FreeBSD (2.2.5-Stable) server with an automounted CDROM (exported
via nfs and samba).
2.) One or more FreeBSD-Clients automounting this CDROM via nfs.
3.) One or more NT-Workstations mounting this CDROM via samba.
I found something like this posted by s.o. for automounting the CDROM on the
server:
/etc/amd.map:
/defaults type:=host;fs:=${autodir}/${rhost};rhost:=${key}
* opts:=rw,grpid,resvport,nfsv2
vulcan type:=auto;\
fs:=${map};\
pref:=${key}/
vulcan/cdrom type:=program;\
fs:=/mnt/cdrom;\
mount:="/sbin/mount mount /mnt/cdrom";\
unmount:="/sbin/umount umount -f /mnt/cdrom"
/etc/fstab:
/dev/cd0a /mnt/cdrom cd9660 ro,noauto 0 0
amd-flags: -c 99999 -l syslog /amd /etc/amd.map
After inserting a CDROM in the drive I can access it from any client...
...but here are the problems:
1.) I have to set the timeout on the server very high, because the nfs-exported
cdrom won't be remounted after the timeout. Instead, I get a stale NFS
handle
on the client and so I have to wait on the client for the timeout, too.
If the server
never times out, I will never get a stale NFS handle at the client. The
problem
which remains, is how to eject the CDROM. The clients don't have a chance
to
get informed by this event. So I've hacked a little script, which sends
the command
'amq -u /mnt/cdrom' to every machine and then runs 'cdcontrol eject' on
the
server. :-(
2.) If there is no CDROM in the drive and I try to access it on the clients I'm
getting a permanent error on the server: "Too many levels of remote in
path".
This message stems from the failing /sbin/mount command and because of
the very long timeout it will stay permanent until the normal timout. I
don't
know why amd doesn't retry a failed program-type mount after a definable
timeout :-(
3.) If somebody on any of the clients is sitting on a nfs-mounted directory
from the CDROM my script will fail, because I can't forcibly unmount a
blocked nfs-mounted directory. The consequence is a stale NFS handle
as in problem 1.)
1.) and 3.) are not a problem for the samba-clients, so maybe a rumba-client
on my FreeBSD-clients won't have these problems either!? But I absolutely
can't handle the second problem. Right know I have to restart amd on the server
If somebody has tried to access an empty CDROM-drive. I think its impossible to
explain to a NT-User, that he never may access an empty CDROM-drive on the
server from his NT-workstation.
I know that changable medias aren't fitting very well into the concept of amd,
but
maybe there is something I've overlooked. So if there is somebody who has spent
some days with similar problems and has has some ideas, please tell me!
Thanks for Your time
Volker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711291154.MAA01209>