Try it yourself. Grab a brand new gcd-token and try to add it through the web gui. It won’t work. I have another post about this I made yesterday here, but then realized later - after more testing - that it should’ve been classified as a bug.
The ultimate problem is that when you add a token based backends, duplicacy-web stores path to the token instead of its content. It also goes extra mile to encrypt the path to the token file. While token files still sits in your Downloads folder and once you delete it backup will break, even if you got lucky to make it work in the first place through the magic of being on the same machine and running duplicacy under the same use.
It’s broken for very long time and needs to be fixed, also for a same amount of time, and counting.
1 Like
So, what’s the solution? I mean, if it was a consistent problem with all token-based backends, then why does it work consistently with the onedrive token? I’d like to add that configuring a google drive with duplicati also works - although, after granting access through google on your browser, they somehow manage to grab the auth id and automagically paste it into the appropriate field - instead of having to manually download a token file.
1 Like
duplicati is using slightly different authentication mechanism. My understanding on web services authentication is very vague… some thing something OAUTh refreshable vs something else…
I’m not sure why duplicacy does not show the same issue for you with OneDrive, I haven’t used OneDrive but iirc it still relies on a token file
Token file contains quite a bunch of stuff, including refresh URLs (via a service hosted on duplicacy.com), it’s not just an actual token.
1 Like
Well, that’s too bad. I guess for now I’ll have to use duplicati, which is a shame because this software came highly recommended. Anyway, thanks for at least getting back to me.
Just because of need to copy a file manually? (You can put a token file somewhere into duplicacy-web accessible location and point it to it)
Duplicati has host of other issues (such as substandard actual backup stability, and lack of stable version) so throwing in a towel on a web-ui front end bug that has an easy workaround is a bit an overreaction. When the choice is slick UI vs stable backup — it’s not really a choice
To be completely frank, I think duplicacy web ui is horrible. It’s a closed source afterthought based on a “control panel” free off-the-shelf genetic component. Probably it’s very hard to make a user friendly slick UI out of it.
Duplicacy’s value is not in that at all. The CLI engine is what earned the reputation and what probably was implied when recommended to you.
It would be great if the UI was usable, but it isn’t, not a big deal. You’d expect to use it only once anyway, to setup, set it and forget it fashion.
I’ll link my personal anecdote of how I came to use duplicacy, despite its UI.
Edit here: Is this project dead? - #9 by saspus
In summary, webUI quality has a lot to be desired, but this is not why a lot of us stick to it. (The CLI engine is)
2 Likes
I see your point, but there’s something else to consider here. Look at it from my perspective. I’m a new user. I have a lot more to administrate in the background besides this. It turns out that there’s an advertised feature that doesn’t work, and even though that feature is of the web gui, it makes it a showstopper, because I can’t even begin to attempt a backup. I’m maintaining other things, so now I have to attempt to learn why this isn’t working, so I search, I fiddle … I eventually start making posts.
However, I also know there’s something else out there that just works the first time I attempt to use it. It’s called “inferior” by many backup snobs out there, but, it solves a problem. Most people are just going to go with what works. It also helps that it’s free, so I’m going to have to disagree with you that the UI not being usable isn’t a big deal. It is. This is paid software. If it’s not usable, then those responsible should either call the web version a beta product, or put a very high priority on addressing the issue.
With that being said, do I want to give this product a chance? Absolutely, because I’m also not like most people. I’m very stubborn. I’ll likely toy with this in the background while duplicati does its thing, which brings me to my next question.
How would I get this to work? I think there’s a misunderstanding here, because after re-reading your comment, I’m pretty certain that I have been putting the token into a web accessible location and pointing to it. It’s just that nothing is happening, unless there’s another way to do this that I’m just not aware of.
1 Like
I’m 100% with you on this one, this is why I got another competing solution to my extended family because it “just works” and is out of the way. And for myself – I stick to CLI. It’s not rocket science to configure launchd daemon or rc script to get it running, and no need to fight through the GUI. Of course, this hardly can be recommended to wide userbase, but oh well.
Yeah, I agree, I re-read your other original thread, and it seem that you are doing everything right, it’s just google drive refuses to enumerate shared drive for some reason.
Two things here:
- Are you using google workspace or a consumer account? Maybe it’s a browser issue? Which browser? I’ll try to reproduce it shortly on a Mac.
- When you say “shared drive” – are you referring to a google team folders or just a folder in “My Drive” shared with another account? If you are trying to do the former – please don’t. Maybe this not working was the universe warning you
Shared drives have a limit of 400,000 items (including files, shortcuts, and folders). Duplicacy will reach it very quickly (in about 500GB backed up, in my experience, give or take).
If you want to backup to another account - share the drive directly. Or, in case of workspace - with the service account it shall work.
And most important bit (again, I’m on the phone, its hard to switch back and forth between topics – but if you are trying to go the service account with impersonation on google workspace route – you would need to ensure you are using CLI version 3.0.1 or newer to get this pr
Indeed, it does not work for me either.
Curiously, the web form that generated the token has never completed – it got stuck on this one with infinite progress bar spinning.:
even though the token got downloaded successfully and duplicacy seems to be authorized, according to a bunch of emails google sent me.
Duplicacy, when fed this token file, (content of which looks fine btw), gets stuck here:
I wonder where did I see this already…
Perhaps google changed API and duplicacy web needs to catch up? There is nothing in the logs though, and behavior is the same in Firefox.
paging @gchen
Yup. It seems you’re getting the same results. I’m glad I was finally able to communicate what I meant. We were probably saying two different things for most of that conversation and not realizing it, so thank you for taking the time out to test it yourself. Whenever the fix is set forth, I look forward to trying it out.
I’m looking into this issue now.
It is working fine for me. It can show the list of Shared Drives. If you don’t have a Shared Drive then the list will be blank.
So then, I’m guessing that personal accounts aren’t supported? Because shared drives in gdrive are only available for eligible work or school accounts, not personal accounts.
Shared Drive is optional. You don’t need to enter a Shared Drive name if you put the storage directory under My Drive.
But this is what I’m doing. Me and @saspus have had the same result, which is what was shared in both of our posts. Out of curiosity, have you tried this from a personal google drive account, and not one that has shared drives?
Ok. I figured it out. It’s a UX nightmare.
@glassman, Basically, don’t click on Shared Drive. Ignore that field. Instead, click on the folder next to Directory field.
I consider myself a “power user” and I stumbled on it after using duplicacy for 4 years. A reasonable person looking at this expect to fill out all fields, – select toke, select shared folder, then select directory in it. Nowhere in the UI is it indicated that the second step can be skipped.
Shared drive and folder, if anything, shall be on the same level.
This is still a bug. An UX bug. Needs to be fixed.
Another annoying thing, is when I downloaded the token, it goes to my Downloads folder. Then when I click to browse for it – why does it start at the root of my drive? Why are folders sorted alphabetically and not by “last added”? Why is there no search? Why do I have to break my eyes scrolling with mouse visually looking for the right folders to click on? /rant…
sigh…
Edit: This minor change would be a drastic improvement preventing people hitting the same deadend:
There is also a typo “T Shared Drive field”
And lastly, if there are no shared drives – the app should not just show blank window – this looks a lot like “web page did not load”. It shall say explicitly – “no shared drives available, please pick a directory in My Drive instead” or somethign along the lines to guide the user.
2 Likes
Rearranging the fields hardly improves anything at all.
Your last paragraph highlighted the real fix here - there’s no point showing both My Drive and Shared Drive, as you can’t have both, so why confuse the user?
It could be a single pulldown Location menu that defaults to My Drive at the top, and you can choose Shared Drives (if available), or it’ll say No Shared Drives Available - greyed-out. Visually, I’d put My Drive, separator ("----- Shared Drives ----"), then a list of Shared Drives. Single option single choice.
That’s your browser settings, obviously (my browser has always prompted me where to save.). And you probably shouldn’t save it to Downloads. I certainly hope no piece of software, let alone Duplicacy, is snooping on where you’re saving downloaded files, so starting at the drive root isn’t unusual.
Suffice to say, this token malarkey needs to be improved.
The GUI should grab the token without the aide of the browser or manual intervention (at least, after the authenticating part), and store it directly in .duplicacy-web.
2 Likes
The point being that even this superficial change in layout will reduce confusion by providing some (slightly better) guidance. But yes, it’s a bandaid. The fix is an actual redesign.
Oh yes indeed. It shall go fetch everything accessible as soon as token is provided and offer a choice right there.
Yes, this is a default browser setting. Very few people change defaults. You and me are not a benchmark here. And yet, all my downloads go to Downloads folder. Automatically. I don’t want extra steps.
Hence, if something is expected to be downloaded by the user via separate browser session — the default open folder must be Downloads. No snooping required. Those locations are standard — ~/Downloads and c:/users/Jose/Downloads.
But ultimately, yes. There should be no token files involved in the first place, eliminating the whole issue altogether, including the need to ingest the content of the token and not leaving it laying around in the downloads, and forcing user to think about where to put it.
The GUI should grab the token without the aide of the browser or manual intervention
Bingo. That’s the way. Ultimately, the whole thing will probably better off scrapped at this point as likely it’s hard to impossible to do anything useful within that third party control panel component. Or maybe someone may volunteer to make an opensource ui that will actually work.
1 Like
The point I’m making is, Duplicacy shouldn’t encourage storing and/or locating the token file in Downloads in any case, by navigating to Downloads from the off - since users will just keep that (very bad) choice of location, dictated by browser, as the easiest.
IMO, it’s not desirable to take the content of the token file and put it elsewhere (e.g. the preference; which is totally unsuitable if you have multiple repos). For one, you want just one location where these keys are stored - the token file itself is perfectly fine in that regard - it just needs to be handled completely by the GUI and recommended in the docs, to put the .json in a safe area for the CLI.
At this point, it might be wise to rethink where Duplicacy puts its global configuration.
Even with CLI, I automatically use -repository as the better option these days, so moving to a single config file a la Rclone, makes better sense, and would allow those tokens to be ingested without replication. (Could even encrypt the config file.)
I’m in agreement with you there.
Despite GChen’s good intentions, the off-the-shelf GUI is problematic in so far as it becoming obsolete in short order, with no room to keep development always progressing. When I last checked, it was already inactive, and so too eventually the GUI components will be inadequate if it’s ever to improve.
IMO the only true path would be to open source it. Either start from scratch or have volunteers work on polishing it, using modern frameworks (albeit keeping it web-based 
).
Obviously this would impact GChen’s income but I believe there’s money to be made from licensing to businesses. After all, my little company pays for several Vertical Backup licences (no GUI), and commercial Duplicacy licences, which we’d still continue to do. Yet improving the GUI experience for ordinary users would seriously ramp up interest in Duplicacy as the defacto backup tool.
2 Likes