Gene Heskett wrote:
> Greetings;
> 
> Despite the fact that the user 'amanda' is a member of the group 'disk', 
> all compilations and new files generated by the user amanda seem to be 
> owned by amanda:amanda instead of the expected amanda:disk.
> 
> The end result is that many of my backup operations are failing because 
> the amanda utility doesn't have perms to delete or write to files 
> actually owned by amanda:disk.
> 
> I just went thru all the directory trees amanda needs to access and 
> chowned everything back the way its supposed to be, but then I built the 
> 20061124 tarball just now, and everything is still owned by 
> 
> amanda:amanda.
> 
> From my  /etc/group file:
> disk:x:6:root,amanda
> 
> So I blew it away, called up KUsr and verified that amanda was indeed a 
> member of the group disk.  Even deleted the user and re-added it and made 
> sure this new copy of amanda was a member of the group disk.
> 
> Then as "amanda", I unpacked it again and rebuilt it, but I still have the 
> same problem.  Because none of the files are owned by amanda:disk, the 
> end result is several megs of dead, can't do a thing code that I'd just 
> as well not bother with the 'make install'.
> 
> Anything that amanda has touched over the last 4 days since I started 
> running it again has been converted to being owned by amanda:amanda, and 
> if the file existed, and was to be deleted as part of the housekeeping, 
> was not because the old file was owned by amanda:disk.  So my backups are 
> being slowly trashed because the indice files are not updatable.
> 
> Whats the deal with FC6 and its owner:group handling?  Am I setting up the 
> user wrong or what?
> 
Perhaps something changed the amanda user's primary group in
/etc/passwd?  When new files are created, the user/group set are
the ones in passwd, and /etc/group is only consulted by the system
if the user is not the owner of the directory, then it checks if it
is in the same group (assuming you have group write perms).

Another possibility is that you are forcing the group amanda runs as
in xinetd to be 'amanda' and not 'disk'.


Frank


-- 
Frank Smith                                      fsmith AT hoovers DOT com
Sr. Systems Administrator                       Voice: 512-374-4673
Hoover's Online                                   Fax: 512-374-4501