date:20170202

Re: amanda-3.3.9 : permission issues ?

2017-02-02 Thread Stefan G. Weichinger

Am 2017-02-02 um 13:20 schrieb Jean-Louis Martineau:

> Either the write-protection tab on the tape or a hardware failure.

great, that was it. thanks.
Hadn't thought of that myself ... always another thing to learn.

Re: big update killed 1 host

2017-02-02 Thread Jon LaBadie

On Sun, Jan 29, 2017 at 10:45:37PM -0500, Jon LaBadie wrote:
> I added updates to my CentOS Amanda server that
> changed the OS release from 7.2 to 7.3.  Amanda
> version remained at 3.3.3.  Before update, all
> clients including the server were working fine.
> 
> After the update, all clients backed up fine
> except the server itself.
> 
> amcheck  -c  gives an error:
>   tcpm_recv_token: Invalid size.
> 
> The amcheck debug file ends with reading a string
> from a socket and saying:
> 
>   amcheck-clients: tcpm_recv_token: invalid size "Executing: 
> /usr/sbin/amandad \
>-auth=bsdtcp amdump amdumpd\n"
>   amcheck-clients: security_stream_seterr(0x7f6be589fac0, tcpm_recv_token: \
>invalid size: "Executing: /usr/sbin/amandad \
>-auth=bsdtcp amdump amdumpd\n")
> 
> The amandad debug file contains these lines:
> 
>   amandad: security_stream_seterr(0x7fcfccf15e00, write error to: \
>Bad file descriptor)
>   amandad: security_seterror(handle=0x7fcfccf14f00, driver=0x7fcfcac0f7e0 \
>(BSDTCP) error=write error to: Bad file descriptor)
> 
> The problem is neither firewall nor selinux
> related as I've turned both off and still see
> the same error.

Just a short reiteration and addition of one piece.

 - Large update of amanda server CentOS 7.2 to 7.3  (900 packages)
 - Amanda went from 3.3.3-13 to 3.3.3-17
 - No amanda config changes
 - Server can backup all remote clients
 - Server can not backup itself
 - amcheck, amdump, amrecover all fail with same error:
   tcpm_recv_token: invalid size "Executing: /usr/sbin/amandad -auth=bsdtcp 
amdump amdumpd\n"

The new data piece, I downgraded to the previous amanda version,
3.3.3-13 and amcheck fails with the same error.  At this kind of
rules out the newer amanda packages as the cause of the problem,
I re-updated them to 3.3.3-17.

So, if the amanda packages are not the problem and my amanda
configuration has not changed, where do I look?

Jon
-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

2017-02-02 Thread Jean-Francois Malouin

* Jean-Louis Martineau <jmartin...@carbonite.com> [20170202 11:10]:
> You can't do a level 1 backup if there is no state file for the level 0 
> (full) backup.
> 
> Force a full backup of the dle with amadmin CONF force HOST DISK

Of course, it makes sense!

Thanks,
jf

> 
> Jean-Louis
> 
> On 02/02/17 11:05 AM, Jean-Francois Malouin wrote:
> > * Jean-Louis Martineau <jmartin...@carbonite.com> [20170202 10:52]:
> >> Do amcheck reported an error?
> > amcheck returns fine.
> >
> >> $ man ambsdtar
> >> STATE-DIR
> >>
> >>  The directory where ambsdtar stores the database it uses to
> >>  generate incremental dumps.  The default is set when Amanda is
> >>  built.
> >>
> >>
> >> Create the /usr/local/share/amanda/bsdtar directory of set the property
> >> STATE-DIR to another directory that exists.
> > As I said, the state-dir /usr/local/share/amanda/bsdtar *already* exists
> > on the client but is empty at the moment as I didn't put back the files
> > that amanda/bsdtar created *before* I rebuilt the VM. If I leave the
> > state dir empty, who should own it and what should the permissions be?
> >
> > Right now:
> >
> > # ls -ld /usr/local/share/amanda/bsdtar
> > drwxr-xr-x2 amanda  amanda  512 Feb  2 09:29 
> > /usr/local/share/amanda/bsdtar
> >
> > thanks,
> > jf
> >
> >
> >
> >> Jean-Louis
> >>
> >>
> >> On 02/02/17 10:12 AM, Jean-Francois Malouin wrote:
> >>> Hi,
> >>>
> >>> I've got this VM running FreeBSD-11 and amanda-client-3.3.6 installed on
> >>> it for testing purposes. Server is 3.4.1. Initial tests worked ok
> >>> (backups and restores) but I had to rebuild the VM from scratch for
> >>> whatever reasons. After reinstalling and configuring amanda on it as I
> >>> previously did, the amanda backup run on it fails with this in the
> >>> amreport:
> >>>
> >>>
> >>> FAILED DUMP DETAILS:
> >>> /-- 172.16.10.104 /ifs lev 1 FAILED [missing size line from 
> >>> sendbackup]
> >>> sendbackup: info BACKUP=APPLICATION
> >>> sendbackup: info APPLICATION=ambsdtar
> >>> sendbackup: info 
> >>> RECOVER_CMD=/usr/local/libexec/amanda/application/ambsdtar restore 
> >>> [./file-to-restore]+
> >>> sendbackup: info end
> >>> ? ambsdtar: error opening 
> >>> /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or 
> >>> directory
> >>> ? dumper: strange [missing size line from sendbackup]
> >>> \
> >>>
> >>> client debug file shows:
> >>>
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 
> >>> euid 140 version 3.3.6: start at Wed Feb  1 21:30:32 2017
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: version 3.3.6
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 
> >>> euid 140 version 3.3.6: rename at Wed Feb  1 21:30:32 2017
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: BSDTAR-PATH 
> >>> /usr/bin/bsdtar
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STATE-DIR 
> >>> /usr/local/share/amanda/bsdtar
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ONE-FILE-SYSTEM yes
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: SIZE ^ *Total bytes 
> >>> written: [0-9][0-9]*
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory 
> >>> is new$
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory 
> >>> has been renamed
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE file changed 
> >>> as we read it$
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^could not 
> >>> open conf file
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Elapsed time:
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Throughput
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : File .* 
> >>> shrunk by [0-9][0-9]* bytes, padding with zeros
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Cannot add 
> >>> file .*: No such file or directory$
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00:

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

2017-02-02 Thread Jean-Louis Martineau

You can't do a level 1 backup if there is no state file for the level 0 
(full) backup.

Force a full backup of the dle with amadmin CONF force HOST DISK

Jean-Louis

On 02/02/17 11:05 AM, Jean-Francois Malouin wrote:
> * Jean-Louis Martineau <jmartin...@carbonite.com> [20170202 10:52]:
>> Do amcheck reported an error?
> amcheck returns fine.
>
>> $ man ambsdtar
>> STATE-DIR
>>
>>  The directory where ambsdtar stores the database it uses to
>>  generate incremental dumps.  The default is set when Amanda is
>>  built.
>>
>>
>> Create the /usr/local/share/amanda/bsdtar directory of set the property
>> STATE-DIR to another directory that exists.
> As I said, the state-dir /usr/local/share/amanda/bsdtar *already* exists
> on the client but is empty at the moment as I didn't put back the files
> that amanda/bsdtar created *before* I rebuilt the VM. If I leave the
> state dir empty, who should own it and what should the permissions be?
>
> Right now:
>
> # ls -ld /usr/local/share/amanda/bsdtar
> drwxr-xr-x2 amanda  amanda  512 Feb  2 09:29 
> /usr/local/share/amanda/bsdtar
>
> thanks,
> jf
>
>
>
>> Jean-Louis
>>
>>
>> On 02/02/17 10:12 AM, Jean-Francois Malouin wrote:
>>> Hi,
>>>
>>> I've got this VM running FreeBSD-11 and amanda-client-3.3.6 installed on
>>> it for testing purposes. Server is 3.4.1. Initial tests worked ok
>>> (backups and restores) but I had to rebuild the VM from scratch for
>>> whatever reasons. After reinstalling and configuring amanda on it as I
>>> previously did, the amanda backup run on it fails with this in the
>>> amreport:
>>>
>>>
>>> FAILED DUMP DETAILS:
>>> /-- 172.16.10.104 /ifs lev 1 FAILED [missing size line from sendbackup]
>>> sendbackup: info BACKUP=APPLICATION
>>> sendbackup: info APPLICATION=ambsdtar
>>> sendbackup: info 
>>> RECOVER_CMD=/usr/local/libexec/amanda/application/ambsdtar restore 
>>> [./file-to-restore]+
>>> sendbackup: info end
>>> ? ambsdtar: error opening 
>>> /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or 
>>> directory
>>> ? dumper: strange [missing size line from sendbackup]
>>> \
>>>
>>> client debug file shows:
>>>
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
>>> 140 version 3.3.6: start at Wed Feb  1 21:30:32 2017
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: version 3.3.6
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
>>> 140 version 3.3.6: rename at Wed Feb  1 21:30:32 2017
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: BSDTAR-PATH 
>>> /usr/bin/bsdtar
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STATE-DIR 
>>> /usr/local/share/amanda/bsdtar
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ONE-FILE-SYSTEM yes
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: SIZE ^ *Total bytes 
>>> written: [0-9][0-9]*
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory is 
>>> new$
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory has 
>>> been renamed
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE file changed as 
>>> we read it$
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^could not open 
>>> conf file
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Elapsed time:
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Throughput
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : File .* 
>>> shrunk by [0-9][0-9]* bytes, padding with zeros
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Cannot add 
>>> file .*: No such file or directory$
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Error exit 
>>> delayed from previous errors
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STRANGE : socket 
>>> ignored$
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ambsdtar: error 
>>> opening /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or 
>>> directory
>>>
>>> But /usr/local/share/amanda/bsdtar exists on the client (although empty
>>> at the moment) and has the ownership and permissions:
>>>
>>> # ls -la /usr/local/share/amanda/bsdtar
>>>

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

2017-02-02 Thread Jean-Francois Malouin

* Jean-Louis Martineau <jmartin...@carbonite.com> [20170202 10:52]:
> Do amcheck reported an error?

amcheck returns fine.

> 
> $ man ambsdtar
> STATE-DIR
> 
> The directory where ambsdtar stores the database it uses to
> generate incremental dumps.  The default is set when Amanda is
> built.
> 
> 
> Create the /usr/local/share/amanda/bsdtar directory of set the property 
> STATE-DIR to another directory that exists.

As I said, the state-dir /usr/local/share/amanda/bsdtar *already* exists
on the client but is empty at the moment as I didn't put back the files
that amanda/bsdtar created *before* I rebuilt the VM. If I leave the
state dir empty, who should own it and what should the permissions be? 

Right now:

# ls -ld /usr/local/share/amanda/bsdtar 
drwxr-xr-x2 amanda  amanda  512 Feb  2 09:29 /usr/local/share/amanda/bsdtar

thanks,
jf



> 
> Jean-Louis
> 
> 
> On 02/02/17 10:12 AM, Jean-Francois Malouin wrote:
> > Hi,
> >
> > I've got this VM running FreeBSD-11 and amanda-client-3.3.6 installed on
> > it for testing purposes. Server is 3.4.1. Initial tests worked ok
> > (backups and restores) but I had to rebuild the VM from scratch for
> > whatever reasons. After reinstalling and configuring amanda on it as I
> > previously did, the amanda backup run on it fails with this in the
> > amreport:
> >
> >
> > FAILED DUMP DETAILS:
> >/-- 172.16.10.104 /ifs lev 1 FAILED [missing size line from sendbackup]
> >sendbackup: info BACKUP=APPLICATION
> >sendbackup: info APPLICATION=ambsdtar
> >sendbackup: info 
> > RECOVER_CMD=/usr/local/libexec/amanda/application/ambsdtar restore 
> > [./file-to-restore]+
> >sendbackup: info end
> >? ambsdtar: error opening 
> > /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or 
> > directory
> >? dumper: strange [missing size line from sendbackup]
> >\
> >
> > client debug file shows:
> >
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
> > 140 version 3.3.6: start at Wed Feb  1 21:30:32 2017
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: version 3.3.6
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
> > 140 version 3.3.6: rename at Wed Feb  1 21:30:32 2017
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: BSDTAR-PATH 
> > /usr/bin/bsdtar
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STATE-DIR 
> > /usr/local/share/amanda/bsdtar
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ONE-FILE-SYSTEM yes
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: SIZE ^ *Total bytes 
> > written: [0-9][0-9]*
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory is 
> > new$
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory has 
> > been renamed
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE file changed as 
> > we read it$
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^could not open 
> > conf file
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Elapsed time:
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Throughput
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : File .* 
> > shrunk by [0-9][0-9]* bytes, padding with zeros
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Cannot add 
> > file .*: No such file or directory$
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Error exit 
> > delayed from previous errors
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STRANGE : socket 
> > ignored$
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ambsdtar: error 
> > opening /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or 
> > directory
> >
> > But /usr/local/share/amanda/bsdtar exists on the client (although empty
> > at the moment) and has the ownership and permissions:
> >
> > # ls -la /usr/local/share/amanda/bsdtar
> > total 24
> > drwxr-xr-x2 amanda  amanda512 Feb  2 09:29 .
> > drwxr-xr-x5 rootwheel 512 Feb  1 16:32 ..
> >
> > I'm kind of lost as to why this worked in the first place and now
> > fails...what should be the ownership and permissions on it?
> >
> > Looking back at the restores on the server of the successful backups of
> > /usr/local on this client I can see the bsdtar state files in there with
> > the permissions:
> >
> > /restore/sim/share/amanda/bsdta

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

2017-02-02 Thread Jean-Louis Martineau

Do amcheck reported an error?

$ man ambsdtar
STATE-DIR

The directory where ambsdtar stores the database it uses to
generate incremental dumps.  The default is set when Amanda is
built.


Create the /usr/local/share/amanda/bsdtar directory of set the property 
STATE-DIR to another directory that exists.

Jean-Louis


On 02/02/17 10:12 AM, Jean-Francois Malouin wrote:
> Hi,
>
> I've got this VM running FreeBSD-11 and amanda-client-3.3.6 installed on
> it for testing purposes. Server is 3.4.1. Initial tests worked ok
> (backups and restores) but I had to rebuild the VM from scratch for
> whatever reasons. After reinstalling and configuring amanda on it as I
> previously did, the amanda backup run on it fails with this in the
> amreport:
>
>
> FAILED DUMP DETAILS:
>/-- 172.16.10.104 /ifs lev 1 FAILED [missing size line from sendbackup]
>sendbackup: info BACKUP=APPLICATION
>sendbackup: info APPLICATION=ambsdtar
>sendbackup: info 
> RECOVER_CMD=/usr/local/libexec/amanda/application/ambsdtar restore 
> [./file-to-restore]+
>sendbackup: info end
>? ambsdtar: error opening 
> /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or directory
>? dumper: strange [missing size line from sendbackup]
>\
>
> client debug file shows:
>
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
> 140 version 3.3.6: start at Wed Feb  1 21:30:32 2017
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: version 3.3.6
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
> 140 version 3.3.6: rename at Wed Feb  1 21:30:32 2017
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: BSDTAR-PATH 
> /usr/bin/bsdtar
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STATE-DIR 
> /usr/local/share/amanda/bsdtar
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ONE-FILE-SYSTEM yes
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: SIZE ^ *Total bytes 
> written: [0-9][0-9]*
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory is 
> new$
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory has 
> been renamed
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE file changed as 
> we read it$
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^could not open 
> conf file
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Elapsed time:
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Throughput
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : File .* shrunk 
> by [0-9][0-9]* bytes, padding with zeros
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Cannot add file 
> .*: No such file or directory$
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Error exit 
> delayed from previous errors
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STRANGE : socket ignored$
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ambsdtar: error opening 
> /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or directory
>
> But /usr/local/share/amanda/bsdtar exists on the client (although empty
> at the moment) and has the ownership and permissions:
>
> # ls -la /usr/local/share/amanda/bsdtar
> total 24
> drwxr-xr-x2 amanda  amanda512 Feb  2 09:29 .
> drwxr-xr-x5 rootwheel 512 Feb  1 16:32 ..
>
> I'm kind of lost as to why this worked in the first place and now
> fails...what should be the ownership and permissions on it?
>
> Looking back at the restores on the server of the successful backups of
> /usr/local on this client I can see the bsdtar state files in there with
> the permissions:
>
> /restore/sim/share/amanda/bsdtar# ls -la
> total 24
> drwxr-xr-x 2  140  140 4096 Feb  2 09:25 ./
> drwxr-xr-x 5 root root  144 Jan 19 07:57 ../
> -rw--- 1  140  140   24 Jan 20 16:33 172.16.20.104_ifs_0
> -rw--- 1  140  140   24 Jan 22 16:31 172.16.20.104_ifs_1
> -rw--- 1  140  140   24 Jan 24 16:32 172.16.20.104_ifs_2
> -rw--- 1  140  140   24 Jan 20 16:32 172.16.20.104_usr_local_0
> -rw--- 1  140  140   24 Jan 24 16:31 172.16.20.104_usr_local_1
>
> 140 is the amanda user UID and GID on the client:
>
> # id amanda
> uid=140(amanda) gid=140(amanda) groups=140(amanda),5(operator)
>
> Thanks,
> jf

Re: amanda-3.3.9 : permission issues ?

2017-02-02 Thread Stefan G. Weichinger

Am 2017-02-02 um 13:20 schrieb Jean-Louis Martineau:

> Either the write-protection tab on the tape or a hardware failure.

asked them to check that, waiting for reply

FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

2017-02-02 Thread Jean-Francois Malouin

Hi,

I've got this VM running FreeBSD-11 and amanda-client-3.3.6 installed on
it for testing purposes. Server is 3.4.1. Initial tests worked ok
(backups and restores) but I had to rebuild the VM from scratch for
whatever reasons. After reinstalling and configuring amanda on it as I
previously did, the amanda backup run on it fails with this in the
amreport:


FAILED DUMP DETAILS:
  /-- 172.16.10.104 /ifs lev 1 FAILED [missing size line from sendbackup]
  sendbackup: info BACKUP=APPLICATION
  sendbackup: info APPLICATION=ambsdtar
  sendbackup: info RECOVER_CMD=/usr/local/libexec/amanda/application/ambsdtar 
restore [./file-to-restore]+
  sendbackup: info end
  ? ambsdtar: error opening /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: 
No such file or directory
  ? dumper: strange [missing size line from sendbackup]
  \

client debug file shows:

Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 140 
version 3.3.6: start at Wed Feb  1 21:30:32 2017
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: version 3.3.6
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 140 
version 3.3.6: rename at Wed Feb  1 21:30:32 2017
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: BSDTAR-PATH /usr/bin/bsdtar
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STATE-DIR 
/usr/local/share/amanda/bsdtar
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ONE-FILE-SYSTEM yes
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: SIZE ^ *Total bytes 
written: [0-9][0-9]*
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory is new$
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory has 
been renamed
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE file changed as we 
read it$
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^could not open 
conf file
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Elapsed time:
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Throughput
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : File .* shrunk by 
[0-9][0-9]* bytes, padding with zeros
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Cannot add file 
.*: No such file or directory$
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Error exit 
delayed from previous errors
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STRANGE : socket ignored$
Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ambsdtar: error opening 
/usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or directory

But /usr/local/share/amanda/bsdtar exists on the client (although empty
at the moment) and has the ownership and permissions:

# ls -la /usr/local/share/amanda/bsdtar
total 24
drwxr-xr-x2 amanda  amanda512 Feb  2 09:29 .
drwxr-xr-x5 rootwheel 512 Feb  1 16:32 ..

I'm kind of lost as to why this worked in the first place and now
fails...what should be the ownership and permissions on it?

Looking back at the restores on the server of the successful backups of
/usr/local on this client I can see the bsdtar state files in there with
the permissions:

/restore/sim/share/amanda/bsdtar# ls -la
total 24
drwxr-xr-x 2  140  140 4096 Feb  2 09:25 ./
drwxr-xr-x 5 root root  144 Jan 19 07:57 ../
-rw--- 1  140  140   24 Jan 20 16:33 172.16.20.104_ifs_0
-rw--- 1  140  140   24 Jan 22 16:31 172.16.20.104_ifs_1
-rw--- 1  140  140   24 Jan 24 16:32 172.16.20.104_ifs_2
-rw--- 1  140  140   24 Jan 20 16:32 172.16.20.104_usr_local_0
-rw--- 1  140  140   24 Jan 24 16:31 172.16.20.104_usr_local_1

140 is the amanda user UID and GID on the client:

# id amanda
uid=140(amanda) gid=140(amanda) groups=140(amanda),5(operator)

Thanks,
jf

Re: amanda-3.3.9 : permission issues ?

2017-02-02 Thread Jean-Louis Martineau

On 02/02/17 04:34 AM, Stefan G. Weichinger wrote:
> gentoo linux, amanda 3.3.9
> same installation worked for months
>
> now the tape isn't written anymore, amflush or amlabel fails.
>
> we cleaned the tape drive, reloaded st module
>
> $ amcheck daily
> Amanda Tape Server Host Check
> -
> Holding disk /mnt/amhold/daily: 52084 MB disk space available, using
> 51984 MB
> slot 1: volume 'ADX514'
> Will write to volume 'ADX514' in slot 1.
> NOTE: skipping tape-writable test
> Server check took 0.109 seconds
>
> Amanda Backup Client Hosts Check
> 
> Client check: 1 host checked in 1.086 seconds.  0 problems found.
>
> (brought to you by Amanda 3.3.9)
>
> --->
>
> I try to label that tape:
>
> $ amlabel -f daily ADX514
> Reading label...
> Volume with label 'ADX514' is active and contains data from this
> configuration.
> Consider using 'amrmtape' to remove volume 'ADX514' from the catalog.
> Writing label 'ADX514'...
> Error writing label: Error writing tapestart header: Kernel gave
> unexpected write() result of "Keine Berechtigung" on device /dev/nst0

Either the write-protection tab on the tape or a hardware failure.

Jean-Louis
>
> I even chowned nst0:
>
> # ls -l /dev/nst0
> crw-rw 1 amanda tape 9, 128  2. Feb 09:44 /dev/nst0
>
> "dmesg" looks good to me.
>
> any ideas, anyone?
>
>
> ah:
>
> $ cat taper.20170202102843.debug
> Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper: pid 29240 ruid 87 euid
> 87 version 3.3.9: start at Thu Feb  2 10:28:43 2017
> Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper: Arguments: daily
> Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper: pid 29240 ruid 87 euid
> 87 version 3.3.9: rename at Thu Feb  2 10:28:43 2017
> Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper:
> Amanda::Taper::Scan::traditional stage 1: search for oldest reusable volume
> Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper:
> Amanda::Taper::Scan::traditional oldest reusable volume is 'ADX515'
> Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper:
> Amanda::Taper::Scan::traditional changer is not fast-searchable;
> skipping to stage 2
> Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper:
> Amanda::Taper::Scan::traditional stage 2: scan for any reusable volume
> Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper: Device is in variable
> block size
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Slot 1 with label ADX514
> is usable
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper:
> Amanda::Taper::Scan::traditional result: 'ADX514' on tape:/dev/nst0 slot
> 1, mode 2
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Amanda::Taper::Scribe
> preparing to write, part size 0, using no cache (PEOM will be fatal)
> (splitter)  (no LEOM)
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Starting  ( -> )>
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Final linkage:
>  -(PULL_BUFFER)->
>  -(PUSH_BUFFER)->
> 
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Building type TAPESTART
> header of 32768-32768 bytes with name='ADX514' disk='' dumplevel=0 and
> blocksize=32768
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Device tape:/dev/nst0
> error = 'Error writing tapestart header: Kernel gave unexpected write()
> result of "Permission denied" on device /dev/nst0'
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Device tape:/dev/nst0
> setting status flag(s): DEVICE_STATUS_DEVICE_ERROR
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Cancelling
>  ->
> )>
> Thu Feb  2 10:28:45 2017: thd-0x2c40c50: taper: xfer-source-holding CRC:
> bee1fd76:1441792
> Thu Feb  2 10:28:45 2017: thd-0x2c40c00: taper: xfer-dest-taper-splitter
> CRC: :0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_utime   : 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_stime   : 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_maxrss  : 25848
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_ixrss   : 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_idrss   : 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_isrss   : 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_minflt  : 5015
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_majflt  : 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_nswap   : 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_inblock : 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_oublock : 24
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_msgsnd  : 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_msgrcv  : 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_nsignals: 0
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_nvcsw   : 11
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_nivcsw  : 4
> Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: pid 29240

amanda-3.3.9 : permission issues ?

2017-02-02 Thread Stefan G. Weichinger


gentoo linux, amanda 3.3.9
same installation worked for months

now the tape isn't written anymore, amflush or amlabel fails.

we cleaned the tape drive, reloaded st module

$ amcheck daily
Amanda Tape Server Host Check
-
Holding disk /mnt/amhold/daily: 52084 MB disk space available, using
51984 MB
slot 1: volume 'ADX514'
Will write to volume 'ADX514' in slot 1.
NOTE: skipping tape-writable test
Server check took 0.109 seconds

Amanda Backup Client Hosts Check

Client check: 1 host checked in 1.086 seconds.  0 problems found.

(brought to you by Amanda 3.3.9)

--->

I try to label that tape:

$ amlabel -f daily ADX514
Reading label...
Volume with label 'ADX514' is active and contains data from this
configuration.
Consider using 'amrmtape' to remove volume 'ADX514' from the catalog.
Writing label 'ADX514'...
Error writing label: Error writing tapestart header: Kernel gave
unexpected write() result of "Keine Berechtigung" on device /dev/nst0

I even chowned nst0:

# ls -l /dev/nst0
crw-rw 1 amanda tape 9, 128  2. Feb 09:44 /dev/nst0

"dmesg" looks good to me.

any ideas, anyone?


ah:

$ cat taper.20170202102843.debug
Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper: pid 29240 ruid 87 euid
87 version 3.3.9: start at Thu Feb  2 10:28:43 2017
Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper: Arguments: daily
Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper: pid 29240 ruid 87 euid
87 version 3.3.9: rename at Thu Feb  2 10:28:43 2017
Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper:
Amanda::Taper::Scan::traditional stage 1: search for oldest reusable volume
Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper:
Amanda::Taper::Scan::traditional oldest reusable volume is 'ADX515'
Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper:
Amanda::Taper::Scan::traditional changer is not fast-searchable;
skipping to stage 2
Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper:
Amanda::Taper::Scan::traditional stage 2: scan for any reusable volume
Thu Feb  2 10:28:43 2017: thd-0x2aca200: taper: Device is in variable
block size
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Slot 1 with label ADX514
is usable
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper:
Amanda::Taper::Scan::traditional result: 'ADX514' on tape:/dev/nst0 slot
1, mode 2
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Amanda::Taper::Scribe
preparing to write, part size 0, using no cache (PEOM will be fatal)
(splitter)  (no LEOM)
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Starting  -> )>
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Final linkage:
 -(PULL_BUFFER)->
 -(PUSH_BUFFER)->

Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Building type TAPESTART
header of 32768-32768 bytes with name='ADX514' disk='' dumplevel=0 and
blocksize=32768
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Device tape:/dev/nst0
error = 'Error writing tapestart header: Kernel gave unexpected write()
result of "Permission denied" on device /dev/nst0'
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Device tape:/dev/nst0
setting status flag(s): DEVICE_STATUS_DEVICE_ERROR
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: Cancelling
 ->
)>
Thu Feb  2 10:28:45 2017: thd-0x2c40c50: taper: xfer-source-holding CRC:
bee1fd76:1441792
Thu Feb  2 10:28:45 2017: thd-0x2c40c00: taper: xfer-dest-taper-splitter
CRC: :0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_utime   : 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_stime   : 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_maxrss  : 25848
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_ixrss   : 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_idrss   : 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_isrss   : 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_minflt  : 5015
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_majflt  : 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_nswap   : 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_inblock : 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_oublock : 24
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_msgsnd  : 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_msgrcv  : 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_nsignals: 0
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_nvcsw   : 11
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: ru_nivcsw  : 4
Thu Feb  2 10:28:45 2017: thd-0x2aca200: taper: pid 29240 finish time
Thu Feb  2 10:28:45 2017

Re: amanda-3.3.9 : permission issues ?

Re: big update killed 1 host

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

Re: amanda-3.3.9 : permission issues ?

FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

Re: amanda-3.3.9 : permission issues ?

amanda-3.3.9 : permission issues ?

10 matches

Site Navigation

Mail list logo

Footer information