Re: Amanda - unable to create temporary directory
Hi All,
I've been experiencing the same error messages with Amanda
2.5.2-20080523
running Solaris 10 125100-07 when I backup *any slice* with using a
non-root
user id.
A quick search on SunSolve threw up the following bug report :
Bug ID: 4961690
Synopsis: roll_log()/make_mp() misuses mktemp(), causing spurious failures of
fsck, ufsdump
State: 5-Cause Known
Description:
See comments.
Date Modified: 2004-06-11 05:50:40 GMT+00:00
http://sunsolve.sun.com/search/document.do?assetkey=1-1-4961690-1
(Note : Above link will require a SunSolve account)
>From what I can gather reading the Bug Report the issue lies with the
permissions that ufsdump is using when creating a temporary mount point
(probably for creating the file index).
The directories in question :
/tmp/.rlg.*
/var/tmp/.rlg.*
/.rlg.*
are created with mode 000 and the *real* user id and not the
effective (root) uid. The 000 mode means that non-root users
cannot access the created directory which causes ufsdump to
try and create the directory under the next directory in it's
prefered list until it fails
Maybe the issue that Benjamin is seeing is due to the failure of
ufsdump to create a temporary mount point when request a Level 2
dump. As ufsdump cannot mount the filesystem to create a list
of modified files to dump, maybe ufsdump 'fallbacks' to a simpler
Level 0 dump?? Just conjection of course...
Regards,
Nick Smith
p.s. Are users seeing lots of .rlg.* directories created -
I am only seeing this on my 2.5.2 test installation but
not on my 2.5.0p2 production servers also running the
same version and patch level of Solaris??
Benjamin Lewis wrote:
> Peter Kunst wrote:
>
> > I have one Solaris9 client with the same issues here:
> >
> > ? Unable to create temporary directory in any of the directories
> listed
> > below:
> > ? /tmp/
> > ? /var/tmp/
> > ? /
> >
> > when using ufsdump. When switching this client (one DLE only) from
> ufsdump
> > to gtar, this message disappears.
> >
> > The strange thing about this client is, even if amstatus tells me
> it's a
> > level 1, it does a level 0 (~50GB every day). Regardless if using
> ufsdump
> > or gtar. And yes, this box is synced using ntp, living in the
> correct
> > century :o)
> >
> > ufsdump is suid root, /tmp, /var/tmp and / have the correct
> permissions.
>
> I think these are symptoms of trying to use ufsdump on a sub-directory
> that is not a mountpoint. ufsdump can do that, but will only do level
> 0
> dumps and will complain about it. Here's a very recent example:
>
> /-- xxx.xxx.xxx.xxx /var/log lev 2 STRANGE
> *** sendbackup: start [xxx.xxx.xxx.xxx:/var/log level 2]
> sendbackup: info BACKUP=/usr/sbin/ufsdump
> sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... -
> sendbackup: info end
> ? Unable to create temporary directory in any of the directories
> listed
> below:
> ? /tmp/
> ? /var/tmp/
> ? /
> ? Please correct this problem and rerun the program.
> | DUMP: Date of this level 0 dump: Mon May 28 12:19:34 2007
> | DUMP: Date of last level 0 dump: the epoch
> *** | DUMP: Dumping /dev/md/rdsk/d11 (xxx.xxx.xxx.xxx:/var) to
> standard output.
> | DUMP: Mapping (Pass I) [regular files]
> | DUMP: Mapping (Pass II) [directories]
> | DUMP: Writing 32 Kilobyte records
> | DUMP: Estimated 389356 blocks (190.12MB) on 0.00 tapes.
> | DUMP: Dumping (Pass III) [directories]
> | DUMP: Dumping (Pass IV) [regular files]
> | DUMP: 389310 blocks (190.09MB) on 1 volume at 5749 KB/sec
> | DUMP: DUMP IS DONE
> sendbackup: size 194655
> sendbackup: end
> \
>
> I prefixed the critical lines with "***". Notice how the message from
> ufsdump says that it's dumping /var at level 0 but Amanda asked for
> /var/log at level 2.
>
> % df /var/log | awk '{print $1}'
> /var
>
> -Ben
>
> --
> Benjamin Lewis, CISSP <[EMAIL PROTECTED]>
> Security Analyst, Identity and Access Management
> IT Networks & Security
> Purdue University
>
Re: Amanda - unable to create temporary directory
Peter Kunst wrote:
> I have one Solaris9 client with the same issues here:
>
> ? Unable to create temporary directory in any of the directories listed
> below:
> ? /tmp/
> ? /var/tmp/
> ? /
>
> when using ufsdump. When switching this client (one DLE only) from ufsdump
> to gtar, this message disappears.
>
> The strange thing about this client is, even if amstatus tells me it's a
> level 1, it does a level 0 (~50GB every day). Regardless if using ufsdump
> or gtar. And yes, this box is synced using ntp, living in the correct
> century :o)
>
> ufsdump is suid root, /tmp, /var/tmp and / have the correct permissions.
I think these are symptoms of trying to use ufsdump on a sub-directory
that is not a mountpoint. ufsdump can do that, but will only do level 0
dumps and will complain about it. Here's a very recent example:
/-- xxx.xxx.xxx.xxx /var/log lev 2 STRANGE
*** sendbackup: start [xxx.xxx.xxx.xxx:/var/log level 2]
sendbackup: info BACKUP=/usr/sbin/ufsdump
sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... -
sendbackup: info end
? Unable to create temporary directory in any of the directories listed
below:
? /tmp/
? /var/tmp/
? /
? Please correct this problem and rerun the program.
| DUMP: Date of this level 0 dump: Mon May 28 12:19:34 2007
| DUMP: Date of last level 0 dump: the epoch
*** | DUMP: Dumping /dev/md/rdsk/d11 (xxx.xxx.xxx.xxx:/var) to
standard output.
| DUMP: Mapping (Pass I) [regular files]
| DUMP: Mapping (Pass II) [directories]
| DUMP: Writing 32 Kilobyte records
| DUMP: Estimated 389356 blocks (190.12MB) on 0.00 tapes.
| DUMP: Dumping (Pass III) [directories]
| DUMP: Dumping (Pass IV) [regular files]
| DUMP: 389310 blocks (190.09MB) on 1 volume at 5749 KB/sec
| DUMP: DUMP IS DONE
sendbackup: size 194655
sendbackup: end
\
I prefixed the critical lines with "***". Notice how the message from
ufsdump says that it's dumping /var at level 0 but Amanda asked for
/var/log at level 2.
% df /var/log | awk '{print $1}'
/var
-Ben
--
Benjamin Lewis, CISSP <[EMAIL PROTECTED]>
Security Analyst, Identity and Access Management
IT Networks & Security
Purdue University
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Amanda - unable to create temporary directory
On Fri, May 25, 2007 at 05:40:00PM -0500, Dustin J. Mitchell wrote: > On Fri, May 25, 2007 at 05:47:33PM -0400, Jon LaBadie wrote: > > ISTR, from your original message, that the "Strange" message said > > unable to create temporary directory under, /tmp, /var/tmp, and /. > > I don't recall it saying anything about /tmp/amanda. I don't > > understand why you are fixed on that particular directory. > > That was confusing me too :) > > To clarify, ufsdump is prbably trying to create temporary files on its > own (who knows why, but lots of programs do it!). Because of some > permissions problem, it is unable to create those files. Likely causes: > - bad permissions on /tmp, /var/tmp, and / > - ufsdump not running as the correct user > - selinux or other kernel-based security mechanisms ^^^ This particular one is not too likely on a system using ufsdump ;) -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Amanda - unable to create temporary directory
Dustin J. Mitchell wrote: On Fri, May 25, 2007 at 05:47:33PM -0400, Jon LaBadie wrote: ISTR, from your original message, that the "Strange" message said unable to create temporary directory under, /tmp, /var/tmp, and /. I don't recall it saying anything about /tmp/amanda. I don't understand why you are fixed on that particular directory. That was confusing me too :) To clarify, ufsdump is prbably trying to create temporary files on its own (who knows why, but lots of programs do it!). Because of some permissions problem, it is unable to create those files. Likely causes: - bad permissions on /tmp, /var/tmp, and / - ufsdump not running as the correct user - selinux or other kernel-based security mechanisms As Jon said, the problem is on the Amanda client, not on the server. Agreed. It's a problem on the client. I have one Solaris9 client with the same issues here: ? Unable to create temporary directory in any of the directories listed below: ? /tmp/ ? /var/tmp/ ? / when using ufsdump. When switching this client (one DLE only) from ufsdump to gtar, this message disappears. The strange thing about this client is, even if amstatus tells me it's a level 1, it does a level 0 (~50GB every day). Regardless if using ufsdump or gtar. And yes, this box is synced using ntp, living in the correct century :o) ufsdump is suid root, /tmp, /var/tmp and / have the correct permissions. A rootkit, maybe ? Peter
Re: Amanda - unable to create temporary directory
On Fri, May 25, 2007 at 05:47:33PM -0400, Jon LaBadie wrote: > ISTR, from your original message, that the "Strange" message said > unable to create temporary directory under, /tmp, /var/tmp, and /. > I don't recall it saying anything about /tmp/amanda. I don't > understand why you are fixed on that particular directory. That was confusing me too :) To clarify, ufsdump is prbably trying to create temporary files on its own (who knows why, but lots of programs do it!). Because of some permissions problem, it is unable to create those files. Likely causes: - bad permissions on /tmp, /var/tmp, and / - ufsdump not running as the correct user - selinux or other kernel-based security mechanisms As Jon said, the problem is on the Amanda client, not on the server. Dustin -- Dustin J. Mitchell Storage Software Engineer, Zmanda, Inc. http://www.zmanda.com/
Re: Amanda - unable to create temporary directory
On Fri, May 25, 2007 at 03:33:34PM -0400, Brian Cuttler wrote: > > Jon, > > I'm confused, apparently not parsing this correctly. > > I believe you are saying that using strings you confirmed that > the message is generated from ufsdump, but that you would not > expect ufsdump to create /tmp/amanda, you would have expected > that from an amanda binary. > > Is this a request to ufsdump by an amanda program to create the > /tmp/amanda directory, so an interaction between the two ? While > I only see this message in amdump output from amanda 2.4.4 it > just occured to me that I need a better look to confirm the issue > as a client or a server located DLE and that I need to check those > systems' OS versions. > > The short question though is "Is there a ready fix" ? > > > I said the message came from ufsdump based on checking with strings > > to see in which binary it was located. It is in ufsdump, not one > > of the amanda programs. I would not expect ufsdump to try to create > > /tmp/amanda. That would be done by one of the amanda binaries. > ISTR, from your original message, that the "Strange" message said unable to create temporary directory under, /tmp, /var/tmp, and /. I don't recall it saying anything about /tmp/amanda. I don't understand why you are fixed on that particular directory. In the report, what is put under the "Strange" section are messages that were unexpected, i.e. no info is built into amanda to deal with those particular messages. Again recalling the original message, you said you checked the server and found nothing wrong. But ufsdump does not run on the server, it runs on the client. And as it is suid root on Solaris, it runs with effective root priviliges though real amanda user id. As to a ready fix, I might be able to tell you that if you can tell me why ufsdump is complaining;) If you become certain the message is innocuous, it can be added to the RE list of "normal" messages in sendbackup-dump.c. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Amanda - unable to create temporary directory
Jon, I'm confused, apparently not parsing this correctly. I believe you are saying that using strings you confirmed that the message is generated from ufsdump, but that you would not expect ufsdump to create /tmp/amanda, you would have expected that from an amanda binary. Is this a request to ufsdump by an amanda program to create the /tmp/amanda directory, so an interaction between the two ? While I only see this message in amdump output from amanda 2.4.4 it just occured to me that I need a better look to confirm the issue as a client or a server located DLE and that I need to check those systems' OS versions. The short question though is "Is there a ready fix" ? > I said the message came from ufsdump based on checking with strings > to see in which binary it was located. It is in ufsdump, not one > of the amanda programs. I would not expect ufsdump to try to create > /tmp/amanda. That would be done by one of the amanda binaries. thank you, Brian
Re: Amanda - unable to create temporary directory
On Fri, May 25, 2007 at 10:32:28AM -0400, Brian Cuttler wrote: > I posted to the web -- but I don't know that it will find its > way back to amanda-users. Besides, the thread was 2 years old... > but its come back to haunt me. > > > --- In [EMAIL PROTECTED], Jon LaBadie <[EMAIL PROTECTED]> wrote: > > > > On Thu, Feb 24, 2005 at 09:04:49AM -0500, Gil Naveh wrote: > > > > > > Hello, > > > > > > Amanda is successfully running on our Solaris Servers. But on Amanda's > > > report (the E-mail it sends after amdump) I get the following STRANGE > > > message: > > > > > > ? Unable to create temporary directory in any of the directories listed > > > below: > > > ? /tmp/ > > > ? /var/tmp/ > > > ? / > > > > > > But when I manually accessed the server as Amanda user - I had no problem > > > creating a folder under /tmp as well as /var/tmp/ ! > > > > > > Any thoughts why am I getting this message? > > > Additionally, can somebody tell me what files does Amada writes under /tmp > > > folder? > > > > I replied to your earlier post on this topic but I don't see my response > > in my archive of the list. > > > > That message is not coming from amanda directly, but coming from ufsdump. > > > > Now the question is why ufsdump, running for amanda, can't deal with those > > directories. I only had one possibility and have little confidence in it. > > > > On my system /usr/sbin/ufsdump is a symbolic link to > > /usr/lib/fs/ufs/ufsdump. > > The latter program is root-owned, set-uid. Perhaps yours has been altered. > > > > $ ls -l /usr/lib/fs/ufs/ufsdump > > -r-sr-xr-x 1 root bin 83820 Apr 12 2004 /usr/lib/fs/ufs/ufsdump > > Jon, > > I was looking at these errors again and it occured to me that > they might be from the 2.4.4 version of senddump, rather than > ufsdump. I have several systems giving this warning and they are > all at 2.4.4, I think perhaps the error is benign and result > from the /tmp/amanda directory already existing and the mkdir > failing. > > I'd love to know for sure as we are reviewing our reports a little > differently now and I'd like to classify and either fix or ignore > these warnings. > I said the message came from ufsdump based on checking with strings to see in which binary it was located. It is in ufsdump, not one of the amanda programs. I would not expect ufsdump to try to create /tmp/amanda. That would be done by one of the amanda binaries. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Amanda - unable to create temporary directory
I posted to the web -- but I don't know that it will find its way back to amanda-users. Besides, the thread was 2 years old... but its come back to haunt me. --- In [EMAIL PROTECTED], Jon LaBadie <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 24, 2005 at 09:04:49AM -0500, Gil Naveh wrote: > > > > Hello, > > > > Amanda is successfully running on our Solaris Servers. But on Amanda's > > report (the E-mail it sends after amdump) I get the following STRANGE > > message: > > > > ? Unable to create temporary directory in any of the directories listed > > below: > > ? /tmp/ > > ? /var/tmp/ > > ? / > > > > But when I manually accessed the server as Amanda user - I had no problem > > creating a folder under /tmp as well as /var/tmp/ ! > > > > Any thoughts why am I getting this message? > > Additionally, can somebody tell me what files does Amada writes under /tmp > > folder? > > I replied to your earlier post on this topic but I don't see my response > in my archive of the list. > > That message is not coming from amanda directly, but coming from ufsdump. > > Now the question is why ufsdump, running for amanda, can't deal with those > directories. I only had one possibility and have little confidence in it. > > On my system /usr/sbin/ufsdump is a symbolic link to /usr/lib/fs/ufs/ufsdump. > The latter program is root-owned, set-uid. Perhaps yours has been altered. > > $ ls -l /usr/lib/fs/ufs/ufsdump > -r-sr-xr-x 1 root bin 83820 Apr 12 2004 /usr/lib/fs/ufs/ufsdump Jon, I was looking at these errors again and it occured to me that they might be from the 2.4.4 version of senddump, rather than ufsdump. I have several systems giving this warning and they are all at 2.4.4, I think perhaps the error is benign and result from the /tmp/amanda directory already existing and the mkdir failing. I'd love to know for sure as we are reviewing our reports a little differently now and I'd like to classify and either fix or ignore these warnings. thanks, Brian > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road(609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) > --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: Amanda - unable to create temporary directory
--- In [EMAIL PROTECTED], Jon LaBadie <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 24, 2005 at 09:04:49AM -0500, Gil Naveh wrote: > > > > Hello, > > > > Amanda is successfully running on our Solaris Servers. But on Amanda's > > report (the E-mail it sends after amdump) I get the following STRANGE > > message: > > > > ? Unable to create temporary directory in any of the directories listed > > below: > > ? /tmp/ > > ? /var/tmp/ > > ? / > > > > But when I manually accessed the server as Amanda user - I had no problem > > creating a folder under /tmp as well as /var/tmp/ ! > > > > Any thoughts why am I getting this message? > > Additionally, can somebody tell me what files does Amada writes under /tmp > > folder? > > I replied to your earlier post on this topic but I don't see my response > in my archive of the list. > > That message is not coming from amanda directly, but coming from ufsdump. > > Now the question is why ufsdump, running for amanda, can't deal with those > directories. I only had one possibility and have little confidence in it. > > On my system /usr/sbin/ufsdump is a symbolic link to /usr/lib/fs/ufs/ufsdump. > The latter program is root-owned, set-uid. Perhaps yours has been altered. > > $ ls -l /usr/lib/fs/ufs/ufsdump > -r-sr-xr-x 1 root bin 83820 Apr 12 2004 /usr/lib/fs/ufs/ufsdump Jon, I was looking at these errors again and it occured to me that they might be from the 2.4.4 version of senddump, rather than ufsdump. I have several systems giving this warning and they are all at 2.4.4, I think perhaps the error is benign and result from the /tmp/amanda directory already existing and the mkdir failing. I'd love to know for sure as we are reviewing our reports a little differently now and I'd like to classify and either fix or ignore these warnings. thanks, Brian > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road(609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) >
Re: Switching to GNUTAR - RE: Amanda - unable to create temporary directory
On Thu, Feb 24, 2005 at 01:14:03PM -0500, Gil Naveh wrote: > > At this point it seems that the best way for us is to switch from ufsdump to > gnutar. > But before doing so - what will happen with the backups that I did so far? > (I backed our data on a tape drive). If you change the "program" in your dumptype from "DUMP" to "GNUTAR", you will not be able to use amrecover to get your data back from the earlier backups. Newer backups yes, older ones no. You could use amrestore and the appropriate dump program or you could temporarily reset the "program" parameter while you do your amrecover. > Does ufsdump and gnutar stores the data the same way? (Does ufsdump level > 0,1... is identical to gnutar level 0,1...) Or does it store the data on a > different format? Same way as far as dumplevels are concerned, but the storage format is totally different. > Does Gnutar is going to store the data twice or is it going to overwrite the > data that was stored by ufsdump? I don't get what you are asking by the "twice" question. But amanda does not overwrite things because you change a parameter. Only when a tape gets reused will the old dump data be overwritten. > Any other concerns that I should keep in mind before switching from ufsdump > to gnutar? Unix systems keep 3 timestamps for each file. Because a dump program avoids accessing the files via the normal filesystem calls, these time stamps are not altered by backing up a file. Tar does work with normal filesystem calls. At least one of the 3 timestames will be affected, either the last time the file was read (shows with ls -la) or the last time the file properties were changed (shows with ls -lc). If you do choose to make the switch, I suggest you do it a few DLE's at a time. Change their dumptypes and then uses amadmin to force a level 0 dump for that DLE the next run. A tar level 1 or 2 will not be much use with a ufsdump level 0. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Todd Kover > Sent: Thursday, February 24, 2005 12:37 PM > To: amanda-users@amanda.org > Subject: Re: Amanda - unable to create temporary directory > > > > Jon LaBadie said: > Still can't get you delete superfluous stuff and to bottom or inline post huh? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Switching to GNUTAR - RE: Amanda - unable to create temporary directory
On Thu, Feb 24, 2005 at 02:16:36PM -0500, Brian Cuttler wrote: > > Gil, > > I'm confused, why would suid be needed on ufsdump - isn't it run > beneith the amanda program (/usr/local/libexec/) rundump which is suid ? > It is not an amanda requirement, it is the way the system supplies ufsdump. I suspect it is so that things like /etc/dumpdates can be updated. Though I'm not sure /etc/dumpdates gets updated when ufsdump is run by an ordinary user. I'm pretty sure that if run by an ordinary user ufsdump would switch id's to do the actual reading of files so that the ordinary user does not get to "backup" files they are not allowed to see under normal circumstances. But there may be a few tasks that require root privleges outside of the actual dumping. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Switching to GNUTAR - RE: Amanda - unable to create temporary directory
Gil, I'm confused, why would suid be needed on ufsdump - isn't it run beneith the amanda program (/usr/local/libexec/) rundump which is suid ? For recovery, personally I use amrestore and pipe it to the required utility so as long as I can figure that out (and its imbedded into the first block on of the archive) its not a big deal. On Thu, Feb 24, 2005 at 01:14:03PM -0500, Gil Naveh wrote: > Thanks for the help, > > At this point it seems that the best way for us is to switch from ufsdump to > gnutar. > But before doing so - what will happen with the backups that I did so far? > (I backed our data on a tape drive). > Does ufsdump and gnutar stores the data the same way? (Does ufsdump level > 0,1... is identical to gnutar level 0,1...) Or does it store the data on a > different format? > Does Gnutar is going to store the data twice or is it going to overwrite the > data that was stored by ufsdump? > > Any other concerns that I should keep in mind before switching from ufsdump > to gnutar? > > Thanks, > gil > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Todd Kover > Sent: Thursday, February 24, 2005 12:37 PM > To: amanda-users@amanda.org > Subject: Re: Amanda - unable to create temporary directory > > > > Jon LaBadie said: > > > On my system /usr/sbin/ufsdump is a symbolic link to > /usr/lib/fs/ufs/ufsdump. > > The latter program is root-owned, set-uid. Perhaps yours has been > altered. > > > > $ ls -l /usr/lib/fs/ufs/ufsdump > > -r-sr-xr-x 1 root bin 83820 Apr 12 2004 /usr/lib/fs/ufs/ufsdump > > We actually strip the setuid bit on ufsdump and this seems to work in > most circumstances. > > We had this problem every night on one specific solaris 9 system, and > no other sol9 or sol8 systems (and our amanda client is installed via a > package, so it's the same across all machines). The solaris boxes are > also installed from the same jumpstart images, so they should all behave > the same. > > This error comes from ufsdump, and near as I've been able to tell, > ufsdump is creating a directory named something like '.rlg.zyaaGR in > each of /tmp and /var/tmp (and failing to be able to in / since it's not > running as root, the jibberish after .rlg. changes with each run). This > directory is called with mode 000 and then ufsdump attempts to create a > file in it, which fails and generates that error message. > > I wasn't able to get ufsdump to behave better (nor did I look for > a patch or try to reset ufsdump to being setuid again) but on that > specific system we had amanda incorrectly configured to backup something > other than the mountpoint of the filesystem, but something inside the > filesystem (that is, instead of /export/home it was /export/home/foo/bar > where the filesystem was mounted on /export/home). > > Switching this to the mountpoint made the error go away. There may be > some limitations in ufsdump that cause you only be able to use ufsdump > this way if you're root (though sounsd lke a bug). > > If you're doing this, and doing it on purpose, I'd suggest using gnutar > instead of dump since incremental dumps don't work right except on > filesystem boundaries. > > If you're not doing this and actually backing up a mountpoint, then > maybe the above info will help track it down. (perhaps the setuid bit, > as Jon suggests). > > -Todd > --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Switching to GNUTAR - RE: Amanda - unable to create temporary directory
Thanks for the help, At this point it seems that the best way for us is to switch from ufsdump to gnutar. But before doing so - what will happen with the backups that I did so far? (I backed our data on a tape drive). Does ufsdump and gnutar stores the data the same way? (Does ufsdump level 0,1... is identical to gnutar level 0,1...) Or does it store the data on a different format? Does Gnutar is going to store the data twice or is it going to overwrite the data that was stored by ufsdump? Any other concerns that I should keep in mind before switching from ufsdump to gnutar? Thanks, gil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Todd Kover Sent: Thursday, February 24, 2005 12:37 PM To: amanda-users@amanda.org Subject: Re: Amanda - unable to create temporary directory Jon LaBadie said: > On my system /usr/sbin/ufsdump is a symbolic link to /usr/lib/fs/ufs/ufsdump. > The latter program is root-owned, set-uid. Perhaps yours has been altered. > > $ ls -l /usr/lib/fs/ufs/ufsdump > -r-sr-xr-x 1 root bin 83820 Apr 12 2004 /usr/lib/fs/ufs/ufsdump We actually strip the setuid bit on ufsdump and this seems to work in most circumstances. We had this problem every night on one specific solaris 9 system, and no other sol9 or sol8 systems (and our amanda client is installed via a package, so it's the same across all machines). The solaris boxes are also installed from the same jumpstart images, so they should all behave the same. This error comes from ufsdump, and near as I've been able to tell, ufsdump is creating a directory named something like '.rlg.zyaaGR in each of /tmp and /var/tmp (and failing to be able to in / since it's not running as root, the jibberish after .rlg. changes with each run). This directory is called with mode 000 and then ufsdump attempts to create a file in it, which fails and generates that error message. I wasn't able to get ufsdump to behave better (nor did I look for a patch or try to reset ufsdump to being setuid again) but on that specific system we had amanda incorrectly configured to backup something other than the mountpoint of the filesystem, but something inside the filesystem (that is, instead of /export/home it was /export/home/foo/bar where the filesystem was mounted on /export/home). Switching this to the mountpoint made the error go away. There may be some limitations in ufsdump that cause you only be able to use ufsdump this way if you're root (though sounsd lke a bug). If you're doing this, and doing it on purpose, I'd suggest using gnutar instead of dump since incremental dumps don't work right except on filesystem boundaries. If you're not doing this and actually backing up a mountpoint, then maybe the above info will help track it down. (perhaps the setuid bit, as Jon suggests). -Todd
Re: Amanda - unable to create temporary directory
Jon LaBadie said: > On my system /usr/sbin/ufsdump is a symbolic link to /usr/lib/fs/ufs/ufsdump. > The latter program is root-owned, set-uid. Perhaps yours has been altered. > > $ ls -l /usr/lib/fs/ufs/ufsdump > -r-sr-xr-x 1 root bin 83820 Apr 12 2004 /usr/lib/fs/ufs/ufsdump We actually strip the setuid bit on ufsdump and this seems to work in most circumstances. We had this problem every night on one specific solaris 9 system, and no other sol9 or sol8 systems (and our amanda client is installed via a package, so it's the same across all machines). The solaris boxes are also installed from the same jumpstart images, so they should all behave the same. This error comes from ufsdump, and near as I've been able to tell, ufsdump is creating a directory named something like '.rlg.zyaaGR in each of /tmp and /var/tmp (and failing to be able to in / since it's not running as root, the jibberish after .rlg. changes with each run). This directory is called with mode 000 and then ufsdump attempts to create a file in it, which fails and generates that error message. I wasn't able to get ufsdump to behave better (nor did I look for a patch or try to reset ufsdump to being setuid again) but on that specific system we had amanda incorrectly configured to backup something other than the mountpoint of the filesystem, but something inside the filesystem (that is, instead of /export/home it was /export/home/foo/bar where the filesystem was mounted on /export/home). Switching this to the mountpoint made the error go away. There may be some limitations in ufsdump that cause you only be able to use ufsdump this way if you're root (though sounsd lke a bug). If you're doing this, and doing it on purpose, I'd suggest using gnutar instead of dump since incremental dumps don't work right except on filesystem boundaries. If you're not doing this and actually backing up a mountpoint, then maybe the above info will help track it down. (perhaps the setuid bit, as Jon suggests). -Todd
Re: Amanda - unable to create temporary directory
On Thu, Feb 24, 2005 at 09:04:49AM -0500, Gil Naveh wrote: > > Hello, > > Amanda is successfully running on our Solaris Servers. But on Amanda's > report (the E-mail it sends after amdump) I get the following STRANGE > message: > > ? Unable to create temporary directory in any of the directories listed > below: > ? /tmp/ > ? /var/tmp/ > ? / > > But when I manually accessed the server as Amanda user - I had no problem > creating a folder under /tmp as well as /var/tmp/ ! > > Any thoughts why am I getting this message? > Additionally, can somebody tell me what files does Amada writes under /tmp > folder? I replied to your earlier post on this topic but I don't see my response in my archive of the list. That message is not coming from amanda directly, but coming from ufsdump. Now the question is why ufsdump, running for amanda, can't deal with those directories. I only had one possibility and have little confidence in it. On my system /usr/sbin/ufsdump is a symbolic link to /usr/lib/fs/ufs/ufsdump. The latter program is root-owned, set-uid. Perhaps yours has been altered. $ ls -l /usr/lib/fs/ufs/ufsdump -r-sr-xr-x 1 root bin 83820 Apr 12 2004 /usr/lib/fs/ufs/ufsdump -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Amanda - unable to create temporary directory
Gil Naveh wrote: Amanda is successfully running on our Solaris Servers. But on Amanda's report (the E-mail it sends after amdump) I get the following STRANGE message: ? Unable to create temporary directory in any of the directories listed below: ? /tmp/ ? /var/tmp/ ? / I think these messages are not from amanda but from the dump program, that is invoked by amanda. Are you sure the dump program you use compatible with the filesystem? e.g. ufsdump for ufs filesystems, etc. Try switching to gnutar if you don't mind the longer estimate time. But when I manually accessed the server as Amanda user - I had no problem creating a folder under /tmp as well as /var/tmp/ ! Any thoughts why am I getting this message? Additionally, can somebody tell me what files does Amada writes under /tmp folder? No files at all. Only in /tmp/amanda . -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Amanda - unable to create temporary directory
Gil, I've managed a few strange things over the years, my errors or compounded bad choices specific to my site... Over tightened security on temp, normal protections are 1777. Configure amanda with one username but modify amanda.conf and choose a different runuser. List of errors goes on but that is all I can think of prior to my 2nd of coffee. You are sure that the user you think is running amanda actually is ? This is a server, client or client/server machine ? I'm pretty sure you can run amdump as one user but configure /etc/inetd.conf to run client as a different user. That is, I'm sure you could but equally certain you don't want to. How do you initiate amdump, crontab for amanda user ? We have at least one system that runs it as bin but does it via a root crontab entry that beings "su - bin", this does not simplify debugging. On Thu, Feb 24, 2005 at 09:04:49AM -0500, Gil Naveh wrote: > > Hello, > > Amanda is successfully running on our Solaris Servers. But on Amanda's > report (the E-mail it sends after amdump) I get the following STRANGE > message: > > ? Unable to create temporary directory in any of the directories listed > below: > ? /tmp/ > ? /var/tmp/ > ? / > > But when I manually accessed the server as Amanda user - I had no problem > creating a folder under /tmp as well as /var/tmp/ ! > > Any thoughts why am I getting this message? > Additionally, can somebody tell me what files does Amada writes under /tmp > folder? > > > Many thanks, > gil > --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
