Re: Bacula backup using S3 cloud storage says 'Volume "ICHSI-0012" is unavailable now'

I have figured out the problem. The upgrade to 16.0 redefined the macro 
%{_libexecdir} to point at /usr/libexec instead of /usr/lib, so the path 
to my key-manager.py file (among other scripts) was wrong. Once I fixed 
this in my config file, the tapes are loaded and backups have resumed!

I figured this out by using "bls" on the cloud storage and noticing the 
path to the key-manager.py file didn't exist on my filesystem. It would 
be super helpful to get more details about this error in some log entry 
somewhere rather than a very unhelpful "The volume is unavailable" message.

I appreciate the help,
-Tom


On 8/7/2026 10:40 AM, Thomas Ruth via Bacula-users wrote:
>
> Yes, I have been using volume encryption the entire time. I'm able to 
> successfully use the key-manager.py tool on the command line with 
> "sudo -u bacula" to retrieve my volume keys.
>
> Below are my cloud configs. These haven't changed in 9 months while 
> this has been working. The only changes really are running a system 
> update and upgrading packages. The bacula packages were recompiled on 
> OpenSUSE Leap 16.0 (via OpenSUSE Build Service) and were part of the 
> package upgrade. Previously they were using the 15.6 compiled 
> packages. I upgraded to 16.0 last week. In order for dependencies to 
> work on 16.0, I needed to create a conf file for sysusers.d for 
> creation of system users, and also update the "Provides" for user() 
> and group(). Not sure why that would effect how bacula-sd functions 
> though. All the user/group permissions on files and processes are 
> still fine.
>
> -Tom
>
> Autochanger {
>   Name = CloudChanger1
>   Device = CloudStorage1-1, CloudStorage1-2
>   Changer Device = /dev/null
>   Changer Command = ""
> }
>
> Device {
>   Name = CloudStorage1-1
>   Media Type = File1
>   Device Type = Cloud
>   Cloud = DOSpaces
>   Archive Device = /var/spool/cloud
>   LabelMedia = Yes
>   Enabled = Yes
>   Autochanger = Yes
>   Random Access = Yes
>   AutomaticMount = Yes
>   Removable Media = no
>   AlwaysOpen = No
>   Maximum Concurrent Jobs = 5
>   Maximum Part Size = 512MB
>   Volume Encryption = Yes
> }
>
> Device {
>   Name = CloudStorage1-2
>   Media Type = File1
>   Device Type = Cloud
>   Cloud = DOSpaces
>   Archive Device = /var/spool/cloud
>   LabelMedia = Yes
>   Enabled = Yes
>   Autochanger = Yes
>   Random Access = Yes
>   AutomaticMount = Yes
>   Removable Media = No
>   AlwaysOpen = no
>   Maximum Concurrent Jobs = 5
>   Maximum Part Size = 512MB
>   Volume Encryption = Yes
> }
>
> Cloud {
>   Name = DOSpaces
>   Description = "DigitalOcean Spaces - ichaos-backup-cold"
>   Driver = S3
>   Host Name = sfo3.digitaloceanspaces.com
>   Blob Endpoint = "https://sfo3.digitaloceanspaces.com/"
>   Bucket Name = ichaos-backup-cold
>   Access Key = "XXXX"
>   Secret Key = "YYYY"
>   Protocol = HTTPS
>   UriStyle = Path
>   Truncate Cache = No
>   Upload = AtEndOfJob
>   #MaximumUploadBandwidth = 2MB/s
> }
>
> On 8/6/2026 11:51 PM, Rob Gerber wrote:
>> A quick note before I go to bed: bacula 15.x provides a new feature: 
>> volume encryption. This volume encryption does what it sounds like it 
>> does - encrypts volumes. This is different from the fd encryption 
>> introduced in older versions of bacula, where the fd controls whether 
>> data is encrypted. (Bacula 15.x continues to support fd encryption, 
>> of course). The new volume encryption is controlled by the sd.
>>
>> Check your sd 'drive' devices. Do any of them have encryption 
>> enabled? See my sample device in my prior email for an example of 
>> that directive.
>>
>> It is not mandatory to use volume encryption. You should understand 
>> how the key files are stored, and separately back them up. Without 
>> the key files, you will be unable to restore your data. Bacula 
>> generates a new key for each volume labeled. I am not aware of any 
>> master key provision in the volume encryption scheme (maybe someone 
>> can correct me here, if I am mistaken).
>>
>> Re: amazon driver: I am curious as to whether it would work correctly 
>> if the problem volume was set to 'used' or something, or another 
>> volume was otherwise provided. Would the amazon driver configuration 
>> you installed then function correctly, proving that it is functional?
>>
>> Robert Gerber
>> 402-237-8692
>> [email protected]
>>
>> On Thu, Aug 6, 2026, 11:56 PM Thomas Ruth via Bacula-users 
>> <[email protected]> wrote:
>>
>>     Thanks for your response. I've installed the awscli tool and
>>     switched the config to use the Amazon driver. I've also added the
>>     BlobEndpoint configuration item. I reloaded the config and that
>>     didn't work. Then I stopped the jobs, restarted bacula-sd, then
>>     resumed the jobs, and that didn't work. Finally I started the job
>>     fresh and I get the same result as before.
>>
>>     I looked through the source code. There is a section starting
>>     with "switch (vol_label_status)" in src/stored/mount.c and the
>>     path I'm running into is part of this:
>>     case VOL_ENC_ERROR:
>>
>>     Is this an encryption problem? I installed updates recently,
>>     perhaps openssl updated and broke something?
>>
>>     -Tom
>>

_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users