This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C2DDE6.401108F0
Content-Type: text/plain;
charset="iso-8859-1"
Update: I finished a tech support call with Veritas. Seems that
Netbackup's backup & restore command lines only work with the primary GID in
/etc/passwd, not the secondary GIDs in /etc/group.
I created this set of files
-rw-r----- 1 mark sysadmin 29 Feb 26 13:53 file1
-rw-r----- 1 mark devadm 29 Feb 26 13:53 file2
-rw-r----- 1 root devadm 29 Feb 26 13:53 file3
"sysadmin" is my primary group in /etc/passwd and "devadm" is a secondary
group in /etc/group.
The bpbackup failed to backup file3 as I neither owned it nor was it
readable by my primary GID. Under unix, and nearly every tool you can think
of, this file is readable. As shown below, non-root restores will fail,
too, if the primary GID of the user cannot write to a directory regardless
of secondary GIDs.
Veritas says they're working on a fix, perhaps a point patch but also maybe
part of the next release.
*grump*
-M
-----Original Message-----
From: Donaldson, Mark [mailto:Mark.Donaldson AT experianems DOT com]
Sent: Tuesday, February 25, 2003 9:42 AM
To: Veritasbu (E-mail)
Subject: [Veritas-bu] Permission errors on restore using CLI bprestore
Hi all,
I'm testing a process in which ordinary users can restore files they've
backed up.
The user runs a non-root script that uses bpbackup to send files to
Netbackup - no problems there. A different script should allow the user to
on-demand restore these files. The problem is that I'm getting permission
errors on the directory to which these files are being restored.
Here's my ID information:
venus:mark$ id -a
uid=1000(mark) gid=14(sysadmin) groups=14(sysadmin),200(devadm)
...as you can see, my userid is a member of the "devadm" group.
Here's the directory to which I'm restoring:
venus:mark$ ls -la /stge
total 50
drwxrwxr-x 7 root devadm 8192 Feb 25 10:21 .
drwxr-xr-x 33 root root 1024 Feb 12 10:37 ..
... the /stge directory allows the "devadm" group full write & read
privileges. I can create and delete files from this point without issue.
Here's the list of files that was backed-up:
venus:mark$ sudo bplist -l -R -keyword "mark:200302241809:test_backup" /
drwxr-x--- mark sysadmin 0 Feb 24 18:08 /stge/testdir1/
-rw-r----- root sysadmin 0 Feb 24 18:08
/stge/testdir1/tfile1
-rw-r----- mark sysadmin 0 Feb 24 18:08
/stge/testdir1/tfile2
-rw-r----- mark sysadmin 0 Feb 24 18:08
/stge/testdir1/tfile3
The logfile for bprestore records the following:
10:23:29 (28787.001) INF - Beginning restore from server venus to client
venus.
10:23:31 (28787.001) /stge/testdir1/
10:23:31 (28787.001) Could not make directory /stge/testdir1: Permission
denied
10:23:31 (28787.001) /stge/testdir1/tfile1
10:23:31 (28787.001) Could not create file /stge/testdir1/tfile1: No such
file or directory
10:23:31 (28787.001) /stge/testdir1/tfile2
10:23:31 (28787.001) Could not create file /stge/testdir1/tfile2: No such
file or directory
10:23:31 (28787.001) /stge/testdir1/tfile3
10:23:31 (28787.001) Could not create file /stge/testdir1/tfile3: No such
file or directory
...it says I can't write to /stge to create /stge/testdir1. I should, a
simple "mkdir" in this directory works fine for me. Is it a problem with
primary group/secondary group?
BTW: Solaris 8, NB 4.5 MP2.
HELP!
-M
------_=_NextPart_001_01C2DDE6.401108F0
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Permission errors on restore using CLI bprestore</TITLE>
<META content="MSHTML 5.50.4923.2500" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=428062222-26022003><FONT face="Courier New" color=#0000ff
size=2>Update: I finished a tech support call with Veritas. Seems
that Netbackup's backup & restore command lines only work with the primary
GID in /etc/passwd, not the secondary GIDs in /etc/group.</FONT></SPAN></DIV>
<DIV><SPAN class=428062222-26022003><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=428062222-26022003><FONT face="Courier New" color=#0000ff
size=2>I created this set of files</FONT></SPAN></DIV>
<DIV><SPAN class=428062222-26022003><FONT face="Courier New" color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT face="Courier New">-rw-r----- 1
mark
sysadmin 29 Feb 26 13:53
file1<BR>-rw-r----- 1
mark devadm 29 Feb
26
13:53 file2<BR>-rw-r----- 1
root devadm 29 Feb
26
13:53 file3</FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT
face="Courier New"></FONT></FONT></FONT></FONT></SPAN> </DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT face="Courier New">"sysadmin" is my primary group in
/etc/passwd and "devadm" is a secondary group in
/etc/group.</FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT
face="Courier New"></FONT></FONT></FONT></FONT></SPAN> </DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT face="Courier New">The bpbackup failed to backup file3 as I
neither owned it nor was it readable by my primary GID. Under unix, and
nearly every tool you can think of, this file is readable. As shown
below,
non-root restores will fail, too, if the primary GID of the user cannot write
to
a directory regardless of secondary
GIDs.</FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT
face="Courier New"></FONT></FONT></FONT></FONT></SPAN> </DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT face="Courier New">Veritas says they're working on a fix,
perhaps a point patch but also maybe part of the next
release.</FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT
face="Courier New"></FONT></FONT></FONT></FONT></SPAN> </DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT
face="Courier New">*grump*</FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT
face="Courier New"></FONT></FONT></FONT></FONT></SPAN> </DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial><FONT size=2><FONT
color=#0000ff><FONT
face="Courier New">-M</FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=428062222-26022003><FONT face=Arial color=#0000ff
size=2> </DIV></FONT></SPAN>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Donaldson, Mark
[mailto:Mark.Donaldson AT experianems DOT com]<BR><B>Sent:</B> Tuesday,
February 25,
2003 9:42 AM<BR><B>To:</B> Veritasbu (E-mail)<BR><B>Subject:</B> [Veritas-bu]
Permission errors on restore using CLI bprestore<BR><BR></FONT></DIV>
<P><FONT size=2>Hi all,</FONT> </P>
<P><FONT size=2>I'm testing a process in which ordinary users can restore
files they've backed up. </FONT></P>
<P><FONT size=2>The user runs a non-root script that uses bpbackup to send
files to Netbackup - no problems there. A different script should allow
the user to on-demand restore these files. The problem is that I'm
getting permission errors on the directory to which these files are being
restored.</FONT></P>
<P><FONT size=2>Here's my ID information:</FONT> <BR><FONT size=2>venus:mark$
id -a</FONT> <BR><FONT size=2>uid=1000(mark) gid=14(sysadmin)
groups=14(sysadmin),200(devadm)</FONT> </P>
<P><FONT size=2>...as you can see, my userid is a member of the "devadm"
group.</FONT> </P><BR>
<P><FONT size=2>Here's the directory to which I'm restoring:</FONT> </P>
<P><FONT size=2>venus:mark$ ls -la /stge</FONT> <BR><FONT size=2>total
50</FONT> <BR><FONT size=2>drwxrwxr-x 7
root devadm 8192 Feb 25
10:21 .</FONT> <BR><FONT size=2>drwxr-xr-x 33
root root
1024 Feb 12 10:37 ..</FONT> </P>
<P><FONT size=2>... the /stge directory allows the "devadm" group full write
& read privileges. I can create and delete files from this point
without issue.</FONT></P><BR>
<P><FONT size=2>Here's the list of files that was backed-up:</FONT> </P>
<P><FONT size=2>venus:mark$ sudo bplist -l -R -keyword
"mark:200302241809:test_backup" /</FONT> <BR><FONT size=2>drwxr-x---
mark
sysadmin 0
Feb 24 18:08 /stge/testdir1/</FONT> <BR><FONT size=2>-rw-r-----
root
sysadmin 0
Feb 24 18:08 /stge/testdir1/tfile1</FONT> <BR><FONT size=2>-rw-r-----
mark
sysadmin 0
Feb 24 18:08 /stge/testdir1/tfile2</FONT> <BR><FONT size=2>-rw-r-----
mark
sysadmin 0
Feb 24 18:08 /stge/testdir1/tfile3</FONT> </P><BR>
<P><FONT size=2>The logfile for bprestore records the following:</FONT> </P>
<P><FONT size=2>10:23:29 (28787.001) INF - Beginning restore from server
venus
to client venus.</FONT> <BR><FONT size=2>10:23:31 (28787.001)
/stge/testdir1/</FONT> <BR><FONT size=2>10:23:31 (28787.001) Could not make
directory /stge/testdir1: Permission denied</FONT> <BR><FONT size=2>10:23:31
(28787.001) /stge/testdir1/tfile1</FONT> <BR><FONT size=2>10:23:31
(28787.001)
Could not create file /stge/testdir1/tfile1: No such file or directory</FONT>
<BR><FONT size=2>10:23:31 (28787.001) /stge/testdir1/tfile2</FONT> <BR><FONT
size=2>10:23:31 (28787.001) Could not create file /stge/testdir1/tfile2: No
such file or directory</FONT> <BR><FONT size=2>10:23:31 (28787.001)
/stge/testdir1/tfile3</FONT> <BR><FONT size=2>10:23:31 (28787.001) Could not
create file /stge/testdir1/tfile3: No such file or directory</FONT> </P>
<P><FONT size=2>...it says I can't write to /stge to create
/stge/testdir1. I should, a simple "mkdir" in this directory works fine
for me. Is it a problem with primary group/secondary group?</FONT></P>
<P><FONT size=2>BTW: Solaris 8, NB 4.5 MP2.</FONT> </P>
<P><FONT size=2>HELP!</FONT> </P>
<P><FONT size=2>-M</FONT> </P></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C2DDE6.401108F0--
|
