Martin Simmons <martin AT lispworks DOT com> wrote:

> I read that glusterfs uses FUSE, so it might be checking something more than
> the uid.  That would explain why a root shell can access the files.  Note that
> the error is "Operation not permitted", which is different from the normal
> "Permission denied" error you get from files made unreadable by chmod.
> 
> Can you try running bacula-fd without passing the -u and -g arguments at all?
> That is slightly different from passing -u root -g bacula.

It took me a few days to get back to this as I was out of town.

After a bit of experimenting, I determined that the -u root has
no impact on the situation, but elimination of the -g bacula
allows the files on the glusterfs filesystem to be backed up
(where they exist in a home directory having mode 0700).

For the moment, I've eliminated -g bacula from the daemon args.

I must say, though, that that is really weird.  If running as root
is sufficient to access it, I wouldn't expect running with the bacula
group ID to block access.  Do you have any idea of the mechanism 
here?  Googling with various terms didn't show anything enlightening,
although I'm not sure if
<http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FAQ#Why_does_cp_return_operation_not_permitted_when_copying_a_file_with_no_write_permissions_for_the_owner.3F>
might be relevent.

Devin


------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users