Re: Problem sharing apt cache through NFS

Panu Matilainen <[email protected]> Tue, 20 Jul 2004 14:53:46 +0300
Newsgroups gmane.linux.conectiva.apt-rpm
Message-ID <[email protected]>
On Tue, 2004-07-20 at 14:49, Andre Costa wrote:
> Hi Panu,
> 
> On Tue, 20 Jul 2004 13:10:14 +0300
> Panu Matilainen <[email protected]> wrote:
> 
> > On Mon, 2004-07-19 at 20:18, Andre Costa wrote:
> > > Hi,
> > > 
> > > this is more a basic UNIX question, but I am pretty sure you guys will
> > > be able to help me out with it: we would like to share
> > > /var/cache/apt/archives among a group of machines, with one of them
> > > acting as the "master repository" from which the rest would mount this
> > > directory, so that we would only need to download packages once.
> > > 
> > > Export permissions on the "master" server are (rw,no_root_squash,sync),
> > > and the filesystem is indeed being mounted rw by root. However, 'apt-get
> > > upgrade' complains with:
> > > 
> > > E: Could not get lock /var/cache/apt/archives/lock - open (13 Permission denied)
> > > E: Unable to lock the download directory
> > > 
> > > Weird thing is that root on the client machines _can_ write and execute
> > > files on the mounted partition... in fact, creating the very same lock
> > > file by hand succeeds.
> > > 
> > > stracing the apt-get call yields this:
> > > 
> > > open("/var/cache/apt/archives/lock", O_RDWR|O_CREAT|O_TRUNC, 0640) = 17
> > > fcntl64(17, F_SETFD, FD_CLOEXEC)        = 0
> > > fcntl64(17, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 EACCES (Permission denied)
> > > 
> > > My feeling is that the problem is obvious, but I must confess I got
> > > stuck. If anyone could shed some light on this, I'd be most grateful =)
> > 
> > Note that it's not the creation of the file which fails, it's the
> > fcntl() call to actually lock it that fails. Are you running the
> > necessary NFS locking daemons on the "master" system?
> 
> Yeah, I thought about it, too. Apparently, it is running; if I run this
> on the server:
> 
> service nfslock status
> 
> it returns:
> 
> rpc.statd (pid 9015) is running...
> 
> Anything else I should check?

Mm.. just realized you'll need to be running the nfslock service on all
the clients as well - IIRC (been a while since I last encountered nfs
locking :). 

	- Panu -