s3qladm can't find s3ql_metadata

[Pete M]

Using v5.4.2 on Debian Bookworm with an AWS S3 bucket, I've run into a problem and wanted to check what was the best way to fix it before I make things worse.

I can mount my file system no problem. I can fsck it too, and s3ql_verify.

I first noticed the problem when trying to run "s3qladm upgrade $BUCKET_URL"

I get the error:

s3ql.backends.common.NoSuchObject: Backend does not have anything stored under key 's3ql_metadata'

I confirmed that the problem is that the file "s3ql_metadata" file has somehow gone missing on the s3 bucket. There are lots of backup ones in the bucket, but should I somehow use my working cached version instead?

What's the best way to minimize the chance of data loss, given that I can seemingly mount my file system perfectly fine?

Thanks!

[Nikolaus Rath]

Pete M <pe...@goteck.co.uk> writes:

> Using v5.4.2 on Debian Bookworm with an AWS S3 bucket, I've run into a
> problem and wanted to check what was the best way to fix it before I make
> things worse.
>
> I can mount my file system no problem. I can fsck it too, and s3ql_verify.
>
> I first noticed the problem when trying to run "s3qladm upgrade $BUCKET_URL"
> I get the error:
> s3ql.backends.common.NoSuchObject: Backend does not have anything stored
> under key 's3ql_metadata'

Why are you trying to upgrade the filesystem? If you are able to mount
it, then it's already at the newest revision - no need to upgrade.

> I confirmed that the problem is that the file "s3ql_metadata" file has
> somehow gone missing on the s3 bucket.

Most likely, it hasn't gone missing, it's not expected to be there in
the most recent file system revision. s3qladm is looking for it because
it's expecting to see an old revision to upgrade from.

Best,
-Nikolaus

[Pete M]

Thanks Nikolaus.

I was in the process of preparing to update to v6.0.0. I was running the upgrade as a sanity-check no-op, thinking it would tell me there's nothing to upgrade. When I got the missing s3ql_metadata warning I was worried it meant something was wrong, so didn't want to make things worse.

I've now updated to v6.0.0, and everything seems ok - fsck and mount work as expected. I still get the same warning if I run the upgrade command, but if the fact that I can mount means I have already upgraded, then I guess there's no issue.

Is there anyway to check that the file system is actually at version 6.0.0, or is the fact that it is mounted by 6.0.0 code sufficient to know that it is the right underlying file system version?

[Nikolaus Rath]

Pete M <pe...@goteck.co.uk> writes:
> On Monday, 4 May 2026 at 13:57:05 UTC+2 Nikolaus Rath wrote:
>> Pete M <pe...@goteck.co.uk> writes:
>>
>> > Using v5.4.2 on Debian Bookworm with an AWS S3 bucket, I've run
>> > into a problem and wanted to check what was the best way to fix it
>> > before I make things worse.
>> >
>> > I can mount my file system no problem. I can fsck it too, and
>> > s3ql_verify.
>> >
>> > I first noticed the problem when trying to run "s3qladm upgrade
>> > $BUCKET_URL" I get the error: s3ql.backends.common.NoSuchObject:
>> > Backend does not have anything stored under key 's3ql_metadata'
>>
>> Why are you trying to upgrade the filesystem? If you are able to mount
>> it, then it's already at the newest revision - no need to upgrade.
>>
>> > I confirmed that the problem is that the file "s3ql_metadata" file
>> > has somehow gone missing on the s3 bucket.
>>
>> Most likely, it hasn't gone missing, it's not expected to be there in
>> the most recent file system revision. s3qladm is looking for it because
>> it's expecting to see an old revision to upgrade from.
>

> I was in the process of preparing to update to v6.0.0. I was running
> the upgrade as a sanity-check no-op, thinking it would tell me there's
> nothing to upgrade. When I got the missing s3ql_metadata warning I was
> worried it meant something was wrong, so didn't want to make things
> worse. I've now updated to v6.0.0, and everything seems ok - fsck and
> mount work as expected. I still get the same warning if I run the
> upgrade command,

Yeah, this is a bug in s3qladm that should be fixed. Thanks for reporting.

> but if the fact that I can mount means I have already
> upgraded, then I guess there's no issue. Is there anyway to check that
> the file system is actually at version 6.0.0, or is the fact that it
> is mounted by 6.0.0 code sufficient to know that it is the right
> underlying file system version?

Yes, the fact that mount.s3ql (or fsck.s3ql) works is a guarantee that
the filesystem is at the right revision. The version information is
included in the filesystem metadata and checked before mounting/checking.


Best,
Nikolaus