The client-side full tree for logs looks like this: [amandabackup@cfile ~]$ ls -ld /var /var/log/ /var/log/amanda/ /var/log/amanda/amandad/ drwxr-xr-x. 23 root root 4096 Nov 12 2013 /var drwxr-xr-x. 13 root root 4096 Sep 14 05:00 /var/log/ drwxr-x---. 4 amandabackup disk 4096 Sep 16 14:37 /var/log/amanda/ drwx------. 2 amandabackup disk 4096 Sep 16 16:11 /var/log/amanda/amandad/
On the server side, it's this: [amandabackup@cback jet1]$ ls -ld /var /var/log/ /var/log/amanda/ /var/log/amanda/amandad/ drwxr-xr-x. 23 root root 4096 Jun 5 17:58 /var drwxr-xr-x. 13 root root 4096 Sep 14 03:35 /var/log/ drwxr-x---. 6 amandabackup disk 4096 Jan 31 2014 /var/log/amanda/ drwx------. 2 amandabackup disk 4096 Sep 16 15:11 /var/log/amanda/amandad/ I can write to /var/log/amanda/amandad on the server side as well, both as amandabackup and root. Thanks again. -M On Tue, Sep 16, 2014 at 5:10 PM, Debra S Baddorf <[email protected]> wrote: > Well, there IS a log on both the client and the server side. Best to > check both. > Those permissions from your client match what mine has, so they seem okay. > Oh, do check them a level higher too, at your /var/log/amanda level > since that’s the top of the logfile tree. > > I use bsdtcp (on some clients) and use a “.amandahosts” file on every > client. I haven’t used ssh keys. > Anybody else have an opinion here? > > Deb Baddorf > Fermilab > > On Sep 16, 2014, at 3:45 PM, Michael Stauffer <[email protected]> wrote: > > > Thanks for the reply. > > I presume that the errors are saying the trouble is writing the log file > on the *client* side, correct? > > > > On the client, it looks like this: > > > > drwx------. 2 amandabackup disk 4096 Sep 16 16:11 > /var/log/amanda/amandad/ > > > > And when logged in as user amandabackup I can write/delete files in > there. > > > > Not sure if this matters: > > I'm using 'bsdtcp' for authentication. And if I try to use ssh keys for > amandabackup login from server to client it's not working for some reason. > But I think that shouldn't matter if I'm using bsdtcp, and also the error > looks like the server is getting to the client alright? > > > > -M > > > > On Tue, Sep 16, 2014 at 4:12 PM, Michael Stauffer <[email protected]> > wrote: > > Amanda 3.3.4 > > > > Hi, > > > > I made some changes to an amanda client. I created a new DLE that > pointed to a dir without world-read/exec permissions, and then amcheck gave > this error: > > > > ERROR: cfile-local: service selfcheck: selfcheck: Failed to > chdir(/jag/cnds): Permission denied > > > > I googled a bit and saw that amcheck runs as user amandabackup so it > couldn't read /jag/cnds. But amdump runs (or its client-side daemon runs) > as root so it can read this dir regardless. > > > > So pushing fwd and running amdump, I got errors like this: > > > > planner: ERROR cfile-local: service sendsize: sendsize: Failed to > chdir(/jag/cnds): Permission denied > > > > So on the client (cfile-local) I tried adding amandabackup to relevant > group to allow read/exec permission on /jag/cnds dir. But that wouldn't > work, I'm not sure why, possibly because the client is an NIS client. So I > removed the amandabackup user, created amandabackup user on the NIS server, > and changed the uid on the client for all amandabackup files to match the > new uid from the NIS server. > > > > Now when I run amcheck/amdump I get errors that it can't create log > files on the client: > > > > WARNING: cfile-local: selfcheck request failed: tcpm_recv_token: invalid > size: "amandad: critical (fatal): Cannot create debug file > \"/var/log/amanda/amandad/amandad.20140916160902.debug\": Permission > denied\namandad: Cannot create debug file > \"/var/log/amanda/amandad/amandad.2014091" > > Client check: 1 host checked in 0.285 seconds. 1 problem found. > > > > Logging on to the cfile-local client, I can read and create files in > /var/log/amanda/amandad/ without problems, as root or amandabackup. > > > > Anyone have any suggestions? I've obviously done something to screw > things up, but can't figure out what. Thanks. > > > > -M > > > >
