preferences error on first launch of 7.0b11 [update to beta 12 and setup sync again]
I got an error notification "1Password Sync - Problem Detected. Update Preferences." on first launch of 7.0b11. I looked at all my preferences but didnt see anything broken - and closed the preferences window.
Didnt happen on 2nd launch.. so not sure what's up? Is my dropbox vault now suspect? Sync seems to work ok?
thanks
1Password Version: 7.0b11
Extension Version: Not Provided
OS Version: OS X 10.13.4
Sync Type: DropBox
Comments
-
I got this right after updating too.
0 -
@erich22, can you double-check that sync is working? Add an item to the vault from another device and confirm it is added to a Mac running beta 11. I have an error in the log that the application does not have permission to read the profile.js file, and sync is broken for me.
0 -
I was able to get sync working again by disabling sync, rebooting, and then re-enabling it.
0 -
I, too, had this error—not on the original installation of beta 11 but only following the first reboot of my Mac after that (when I also had both my iOS devices active). I tried WLAN sync with both devices and it worked without any problem.
I am using beta 11 with macOS 10.13.4 and both iOS devices are running iOS 11.3.1.
Edit: I ought probably say that I've been using opvault for a very long time.
Stephen
0 -
@Stephen_C: I'm really intrigued as to how that error would happen with WLAN Server. Are you by any chance also using Folder Sync? If you're using OPVault at all that seems likely. :)
0 -
@brenty although I did use folder sync many moons ago with 1Password 6 I stopped using it ages ago—and well before I used the 1Password 7 betas. I can confirm that 1Password 7 > Preferences > Sync Also sync Primary vault with is set to None. I started using opvault as soon as it was enabled (through, originally, I vaguely recall, some work around) in 1Password 6 and have always used WLAN sync. Although (and I should have said this before—sorry) I do sync a different shared vault to Dropbox...so perhaps the error related to that. The error message did not specify any specific sync form, so far as I recall, so I automatically assumed it related to my principal sync, which is WLAN.
Stephen
0 -
interesting. cecked by adding an entry to my two vaults via ios app. I can see them on my other ios devices, and the primary vault sync'd ok on MacOS, but the secondary vault did NOT?
Weird
0 -
I just got this error with beta 11 as well, although I'm pretty sure I understand why, the error message notification is effectively useless. Clicking it doesn't bring up the preferences, it just brings the app forward.
0 -
OK, updated to 7.0b12, and was able to re-log into the second vault that wasn't sync'ing. Now everything's fine!!
Please mark the thread 'closed' :)
0 -
Also, I think I may have a hint as to why this happened. I am running a two-dropbox configuration. That is have two dropboxes running, sync'ing to two separate dropbox accounts. The vault that failed was located in a dropbox folder not named '~user/Dropbox'. It all worked fine once I connected it again -- but maybe that had something to do with it. I also notice that to set up the connection it wanted dropbox app running -- I don't think this should be a requirement... Dropbox is very battery unfriendly
but as long as the vault is there in the folder you should be able to open it???0 -
although I did use folder sync many moons ago with 1Password 6 I stopped using it ages ago—and well before I used the 1Password 7 betas. I can confirm that 1Password 7 > Preferences > Sync Also sync Primary vault with is set to None. I started using opvault as soon as it was enabled (through, originally, I vaguely recall, some work around) in 1Password 6 and have always used WLAN sync. Although (and I should have said this before—sorry) I do sync a different shared vault to Dropbox...so perhaps the error related to that. The error message did not specify any specific sync form, so far as I recall, so I automatically assumed it related to my principal sync, which is WLAN.
@Stephen_C: Thanks for letting me know! Can you double check to see if you still have the other vault syncing? The reason I ask is that you wouldn't have an OPVault if you were only using WLAN Server, as it doesn't use an external vault sync container like that. So I do think it's something with the vault you're syncing with Dropbox. What is the path? 1Password 7 is sandboxed, so that may be what's causing the trouble, if it cannot access that location.
0 -
interesting. cecked by adding an entry to my two vaults via ios app. I can see them on my other ios devices, and the primary vault sync'd ok on MacOS, but the secondary vault did NOT?
OK, updated to 7.0b12, and was able to re-log into the second vault that wasn't sync'ing. Now everything's fine!! Please mark the thread 'closed' :)@erich22: I don't think we're quite finished here, but I am glad to hear that things are working better for you now! :)
Also, I think I may have a hint as to why this happened. I am running a two-dropbox configuration. That is have two dropboxes running, sync'ing to two separate dropbox accounts. The vault that failed was located in a dropbox folder not named '~user/Dropbox'. It all worked fine once I connected it again -- but maybe that had something to do with it. I also notice that to set up the connection it wanted dropbox app running -- I don't think this should be a requirement... Dropbox is very battery unfriendly but as long as the vault is there in the folder you should be able to open it???
That's very interesting. Thank you for sharing! I do think this is the problem. 1Password 7 is sandboxed, so it may be that it cannot access the location of one (or more) of your vaults.
While I do understand your point about not necessarily needing the Dropbox client running to sync with a folder there, that isn't something we can recommend or support, for a few reasons:
- The Dropbox app does need to be running in order to sync. Arguably, if you're setting up 1Password's sync settings to use Dropbox, that's par for the course. We want to make sure that people don't run into issues with their data not syncing.
- Not having Dropbox running (and therefore syncing) can also cause problems when it is able to sync again, in the form of sync conflicts that happen due to data being changed on multiple devices but not actually syncing until much later.
These things do not offer a good experience for 1Password users, so we do want Dropbox running if that's what's being used to sync the data.
Also, while I won't dispute that Dropbox has some impact on battery life (like any running process), I have to say that it's never been an issue for me. It averages about 100MB RAM and 0.3% CPU here on my aging MacBook Pro 15" (which is not great battery life to begin with), and I don't ever see it anywhere near the top of the list in Activity Monitor. So I wonder if your "dual Dropbox" setup is also contributing to battery life issues in some way (I've never heard of that before, so I have no idea what the impact would be) — or if something else entirely is the culprit. Just some thoughts based on my own experience.
0 -
Can you double check to see if you still have the other vault syncing?
It was indeed related to my shared Dropbox vault which was failing to sync. Disabling sync, deleting the vault on Dropbox and re-enabling sync got everything working again. I was misled by the generic error message (which didn't specifically mention Dropbox) and assumed it must relate to WLAN sync.
The reason I ask is that you wouldn't have an OPVault if you were only using WLAN Server, as it doesn't use an external vault sync container like that
I thought I recalled following some instructions, many moons ago, which enabled me to change to opvault even though I was using WLAN sync. My memory could well be faulty!
Stephen
0 -
It was indeed related to my shared Dropbox vault which was failing to sync. Disabling sync, deleting the vault on Dropbox and re-enabling sync got everything working again. I was misled by the generic error message (which didn't specifically mention Dropbox) and assumed it must relate to WLAN sync.
@Stephen_C: Great! Just wanted to make sure you were all set. We'll see if we can make the errors clearer.
I thought I recalled following some instructions, many moons ago, which enabled me to change to opvault even though I was using WLAN sync. My memory could well be faulty!
Certainly if you were syncing it to a local folder you'd have an OPVault (or AgileKeychain) there. And there's nothing stopping you from using WLAN Server at the same time. But if you're only using WLAN Server, iCloud, or not syncing at all, there will be no vault container on disk, just 1Password's internal database. Clear as mud, eh? :lol:
0 -
For everyone here:
Beta 12 has a fix that can help with this. It will require setting up sync again, but once you do 1Password should be able to continue to sync going forward.
Thanks everyone for the feedback, and for participating in the beta in the first place! :)
0 -
"That's very interesting. Thank you for sharing! I do think this is the problem. 1Password 7 is sandboxed, so it may be that it cannot access the location of one (or more) of your vaults." in your earlier comment to my post above.
When I re-chose this vault in the dropbox not under ~user/Dropbox, 1P Was able to see it from that point forward.. does that break the sandboxing - or did I specifically override it by selecting another location? Wondering about whether you want to post a warning to me when I break the sandboxing - so that I know the risk I'm taking as a user?
Also, fwiw and I realize mine not your typical CONOPS, but when I relinked I did have an instance of DropBox running - but is was the instance syncing the other vault -- the one in ~user/Dropbox. I hadn't started the instance yet for the non-sandboxed vault as I didnt know what was going on. Strictly speaking it should not have shown as running...
But that's probably deep in the weeds.
Everything is still working great since my relinking of the vault btw -- many days later. My two-dropbox config with vaults in each lives on.
0 -
When I re-chose this vault in the dropbox not under ~user/Dropbox, 1P Was able to see it from that point forward.. does that break the sandboxing - or did I specifically override it by selecting another location?
@erich22: Exactly. The problem was that this wasn't being retained with earlier betas, hence beta 12 being the solution for this.
Wondering about whether you want to post a warning to me when I break the sandboxing - so that I know the risk I'm taking as a user?
Sandboxing isn't to "protect" you from accessing the files you want to; rather, it's to prevent a rogue app you download from accessing whatever it wants. The fact that you have to explicitly select the file yourself, and that the app could not do so on its own otherwise (hence the sync errors) demonstrates that. There isn't a way for you to do that without knowing it (okay, unless maybe you partied a little too much beforehand), and that isn't "breaking" sandboxing, as the app will still not have the ability to access other stuff, just what's covered in its built in entitlements, and the specific files you've selected. Definitely confusing, but does that help?
Also, fwiw and I realize mine not your typical CONOPS, but when I relinked I did have an instance of DropBox running - but is was the instance syncing the other vault -- the one in ~user/Dropbox. I hadn't started the instance yet for the non-sandboxed vault as I didnt know what was going on. Strictly speaking it should not have shown as running... But that's probably deep in the weeds.
Maybe, but I'm interested in following you there. Can you clarify this for me though? I'm not sure what you're asking. Maybe my explanation above indirectly answers your question. Maybe not. :lol:
Everything is still working great since my relinking of the vault btw -- many days later. My two-dropbox config with vaults in each lives on.
Awesome! Glad to hear it! Again, this isn't something we can recommend or support (and I'm not 100% sure Dropbox does either), but if it works for you, everyone wins. :)
0
