Creating Initial Repository... failed loading reflog (3 - network failure)

I’m trying to setup CernVM-FS server with minio backend. When running:

cvmfs_server mkfs -s myminio.conf -w http://svl-registry-minio:9000 vasilyobj5.repo.name

I’m getting the following error:

Creating Configuration Files… done
Creating CernVM-FS Master Key and Self-Signed Certificate… done
Creating CernVM-FS Server Infrastructure… done
Signing 30 day whitelist with master key… done
Creating Initial Repository… failed loading reflog (3 - network failure)
reflog hash specified but reflog not present
fail! (cannot sign repo)

Here is the content of myminio.conf:

CVMFS_S3_HOST=svl-registry-minio
CVMFS_S3_PORT=9000
CVMFS_S3_ACCESS_KEY=dummykey
CVMFS_S3_SECRET_KEY=dummykey
CVMFS_S3_BUCKET=cvmfsstore
CVMFS_S3_DNS_BUCKETS=false

When listing the contents of cvmfsstore bucket I can see that some objects related to vasilyobj5.repo.name repository are created:

AWS_ACCESS_KEY_ID=dummykey AWS_SECRET_ACCESS_KEY=dummykey /usr/local/bin/aws s3 --endpoint http://svl-registry-minio:9000 ls s3://cvmfsstore/
PRE vasilyobj5.repo.name/

So, it seems CernVM-FS server does have enough permissions to create objects in the bucket.

Any suggestions? How can I debug this? Thank you!

The minio “download” bucket policy is unfortunately not equivalent to a public ACL. Try setting the acl with s3cmd like s3cmd --acl-public setacl s3://<BUCKET NAME>.

Thanks, Jacob. I set the bucket policy to public with mc (minio client):

./mc policy set public MYMINIO/cvmfsstore

And I’m able to get objects from the minio with regular wget, e.g.:

wget http://svl-registry-minio:9000/cvmfsstore/vasilyobj5.repo.name/.cvmfsreflog

but still the “cvmfs_server mkfs” fails. Do you thin I should still use s3cmd, it might do something differently than mc tool?

Thanks!

Ah, it might be the stratum 0 URL of the -w parameter. It should include the bucket, i.e.

-w http://svl-registry-minio:9000/cvmfsstore vasilyobj5.repo.name

You probably need to recreate the bucket before the mkfs command succeeds because you might have some traces from the previous mkfs command that would interfere with a new attempt.

Hey-hey, that worked, thank you!