1) I changed the permissions on /mnt/sdb1 using I chmod 777 so everyone has read/write/execute privilege. This seemed like overkill since I thought that my problem was related to my labels and pools not being defined properly. So, I did step 2.

2) I used the conf files for bacula-dir.conf and bacula-sd.conf as described in Automated Disk Backup from the bacula manual to define my pools.

I ran a test full backup for job, backupclient1, my default job, and it ran successfully. What I found interesting is the permissions on the backup file. Take a look...

I didn't even know that I had a group called tape. Here is that group...note it has one member...bacula!

Thinking that permissions 777 were too open, I changed them back to 775 and re-ran my backup job. It failed again. I checked the groups again and saw that there was also a "disk" group with no members. I added bacula to that group and re-ran my job. It failed. I then set my permissions back to 777 and ran my job. It succeeded. 

So, even though "bacula" is a member of both "tape" and "disk", the backup fails unless "othe"r has write permissions on /mnt/sdb1. 

Obviously either I don't understand how permissions work or some other account is writing to disk...so the other group must have write permission.

Well, at least the backups are working. the second backup was entitled; Inc-002.

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users