I just pushed 0.8.0-beta1 to GitHub releases and APT/RPM repositories (testing channel).
I would appreciate everyone could take it for a spin and report any issues here.
We’ll probably stay in beta for around a month to be able to fix any issues discovered by the community - there are some big and exciting changes this time.
Release notes and downloads can be found here:
Kopia server is returning an ACCESS_DENIED error when attempting to connecting to S3 via storage configuration after upgrading to 0.8.0-beta1 - see screenshot:
Also seeing ACCESS_DENIED error in Kopia server when attempting to connecting to S3 using repository token - and noticed that the username and hostname are blank (which isn’t the case when using the repository token in 0.7.3)
Connecting via Kopia CLI works as expected. I am using htpasswd auth for the Kopia server user.
If I create a repository user via kopia user add and restart Kopia server with the --allow-repository-users flag in place of the
--htpasswd-file flag, I am unable to get past the login prompt in my web client:
I can’t say, that I can reproduce this issue. I can login with either of my two users to my Kopia repo server using KopiaUI or a webbrowser. Have you checked your running processes, if the option is actualy active on your Kopia server?
@davidhealy can you file an issue on GitHub and provide step-by-step repro here? Looks like you’re trying two different things at the same time (kopia repository server + connecting to S3 via UI) so probably usernames/passwords are somehow getting confused here.
I’d like to understand your scenario better. Also if you have time, can you hop on https://slack.kopia.io and we can chat more interactively?
Thanks for the quick reply - I’ve opened as an issue here After upgrade to 0.8.0-beta1, unable to access S3 repo via Kopia server · Issue #880 · kopia/kopia · GitHub
Thanks. I think I understand the issue and have a solution. See the GH issue.
Hi, for me the new release works well.
I use KopiaUi and Kopia API Server via HTTPS. I was a little confused about the need to use a registered user and the flag —allow-registered-users (?)…
Thank you so much!
What about supporting VSS on windows?
Which part sounds confusing?
For the VSS the building blocks are there (actions) but we don’t have it working e2e yet b
Confused when exactly to use
—password
—server-password
—server-user
—server-cert-fingerprint
—allow-registered-users
The —help parameter shows sometimes too many options I think.
On first connect with kopia-ui I got any user and any snapshots shown. Like on connecting with Firefox. But after adding an user to the repo the list has gone and only the button „New snapshot“ is shown in kopia-ui.
Under what conditions the old invisible standard user „kopia“ can be used to get kopia-ui connected to a kopia server, and what is then the password ?
I admit this is convoluted as there are many passwords at play here and different combinations of flags serve at least 3 different sets of scenarios. I’ll try to write better documentation for it.
The short answer is - if you don’t use Kopia server you don’t need any of these flags - that’s a common scenario. Password is managed automatically for you in OS keychain/credential manager.
For a server scenario I don’t want to risk confusing more people by posting an answer here, please ping me privately with a specific question and I can help unblock you.
When using Kopia server, enabling “Disable Parent Policy Evaluation” removes all retention labels, regardless of what other retension policy has been set.
How to reproduce:
set a retension policy for a snaphot, say:
{
“retention”: {
“keepLatest”: 1,
“keepDaily”: 7,
“keepWeekly”: 4,
“keepMonthly”: 3
},
“files”: {},
“errorHandling”: {},
“scheduling”: {
“intervalSeconds”: 21600
},
“compression”: {
“compressorName”: “gzip-best-compression”
},
run snapshots, in my case a snapshot each 6 hrs to get this:
Now, enable “Disable Parent Policy Evaluation” and check your snapshots again:
{
“retention”: {
“keepLatest”: 1,
“keepDaily”: 7,
“keepWeekly”: 4,
“keepMonthly”: 3
},
“files”: {},
“errorHandling”: {},
“scheduling”: {
“intervalSeconds”: 21600
},
“compression”: {
“compressorName”: “gzip-best-compression”
},
“actions”: {},
“noParent”: true
}
This looks like a bug, probably the same class as
I’ll try to reproduce it and fix it.
