Dropbox Sync Fails After Restarting Computer [confirmed, MAS sandboxing bug]

pappjo

I'm going to use the troubleshooting utility too but I wanted to post this here. I've noticed on both of our computers running 4.1 that if we restart our computers and then add a new log in item a sync to Dropbox does not occur. If I open 1Password's preferences under syncing it says a sync just occurred but checking the Dropbox folder I find that nothing has been updated and the added log in does not sync to our other devices.

To trigger an actual sync I have to disable syncing and then re-select the Dropbox folder. At that time an actual sync does occur which I can see in the Dropbox folder and our other devices pick up the added log in. As long as we don't restart the computers syncing proceeds correctly with any added items but a restart breaks it again. This is on two new retina Macbook Pros running the latest Mavericks version.

I will add a link to this post in the email with the diagnostic.

[Moderator: This was originally posted in Dropbox sync silently fails.]

pappjo

From Megan

Hi everyone,

I've merged several similar posts together so that we work through this together. Right now, our developers are aware of an issue for Mac App Store users (those on 1Password 4.0.8) where Dropbox can become unlinked after a reboot. This seems to be related to the MAS's sandboxing regulations and generally applies to users who have their 1Password.agilekeychain stored in a custom location. Moving your keychain to the standard location

Dropbox/1Password/1Password.agilekeychain will help until we find a proper solution.

If you do find that Dropbox has stopped syncing in this situation, disabling and then re-enabling Dropbox sync will refresh your permissions and syncing will resume.

For users on 4.0.9, we would love to see a Diagnostics Report to better track down where things are going wonky for you!

This is exactly my issue on two retina Macbook Pros that were set up as new using 1Password 4.1 and Dropbox. This issue continues for us and requires that we re-select Dropbox after any computer restart to get syncing working again. I created my own thread about the issue before I came across this old one that mentioned this issue. I have also already submitted a diagnostic report with a link to the thread I created. When might a solution to this be forthcoming since it does still persist in 4.1? Our 1Password.agilekeychain is not in a custom location but in the default Dropbox root folder.

[Moderator: This was originally posted in Dropbox sync silently fails.]

pappjo

It turns out that creating a "1Password" folder within the Dropbox folder and then placing the 1Password.agilekeychain in that folder solves the issue. When our 1Password apps were updated to version 4 that keychain was placed by default in the root Dropbox folder not within a subfolder. That was the way the installation went on all 3 of our computers but apparently that's what enables the access permission to be broken upon a restart.

I've had to go to each computer and create a new 1Password folder within Dropbox and then place the keychain within it. When 1Password was restarted it created a new keychain outside that folder but I moved that one to the desktop just in case and then went through disabling sync. I then re-selected Dropbox and this time chose the subfolder "1Password" to sync with. After doing that and experimenting through several restarts on each computer syncing proceeded correctly each time. I believe that this necessity of a subfolder should be clearly expressed to all version 4 users. It wasn't obvious to me until I read through all those posts and saw that mentioned a couple of times. Also once this version is installed why isn't that subfolder created by default?

sjk

Hi, @pappjo.

I've merged your two posts from the other topic into this one that you created and removed a duplicate. It's easier having them all under one hood, :)

I'm sorry you've had this trouble with Dropbox syncing and am glad to hear you did get it working again.

About some of your issues/concerns:

This issue continues for us and requires that we re-select Dropbox after any computer restart to get syncing working again.
…
When might a solution to this be forthcoming since it does still persist in 4.1?
…
It turns out that creating a "1Password" folder within the Dropbox folder and then placing the 1Password.agilekeychain in that folder solves the issue.

I addressed those in a recent reply:

Disabling/reenabling syncing should continue to be the "suitable workaround" for that, e.g. after system restarts.

Also, Dropbox syncing can be less likely to fail with a 1Password keychain located in Dropbox/1Password/1Password.agilekeychain.

I apologize for the inconvenience of this and we will have it fixed with an update as soon as possible.

You also wrote and asked:

I believe that this necessity of a subfolder should be clearly expressed to all version 4 users. It wasn't obvious to me until I read through all those posts and saw that mentioned a couple of times. Also once this version is installed why isn't that subfolder created by default?

If just the Dropbox root folder is selected when initially configuring Dropbox sync for a vault then a 1Password subfolder is created (if necessary) and used for the keychain by default.

There are valid reasons why people may prefer or need to store keychains in different locations, especially for syncing with multiple vaults.

Please let me know if there's anything else I can help you with.

Happy New Year!

pappjo

Thanks for the reply. The subfolder in Dropbox seems to be working. But I'm still confused. On two of our computers which are new and set up from scratch, we did not have a previous version of 1Password on them version 4 was installed directly from the Mac App store. We have been using the app for a long time but on other computers. When it was installed and Dropbox selected no subfolder was created just the keychain installed in the main Dropbox folder. So until I read your reference to it as well as some others I had never thought about checking that. Also why would a restart disable the syncing to the keychain if it's in the main Dropbox folder as opposed to a subfolder?

sjk

Hi, @pappjo.

I'm not sure (yet) why the 1Password subfolder wasn't created/used when you originally configured Dropbox sync with 1P4. It works that way here, even for a secondary vault when the Dropbox root is selected and a 1Password subfolder doesn't exist, e.g.:

Also why would a restart disable the syncing to the keychain if it's in the main Dropbox folder as opposed to a subfolder?

Could be the intermittent security scoped bookmark issue that @dteare mentioned in what I quoted here. That's also happened with iCloud syncing.

pappjo

Not sure I understand scoping but it all seems to be working now so I'm happy unless this pops again. Thanks again for the reply, I'm sure you guys have been busy.

sjk

Hi again, @pappjo. :)

If you look in this file:

Library/Containers/2BUA8C4S2C.com.agilebits.onepassword-osx-helper/Data/Library/Logs/1Password/2BUA8C4S2C.com.agilebits.onepassword-osx-helper.log

… you'll probably find errors like this:

408001 [APP:0x7fc21ad073d0:] E securityScopedBookmarkDataForURL: | Error creating bookmark data for file:///Users/me/Dropbox/Foo/: (null) 408001 [APP:0x7fc21ad073d0:] E securityScopedURLFromBookmarkData: | Unable to create URL from bookmark data (stale=NO): Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened."

Also see this new Announcement post:

1Password Losing Sync Permissions after System Restart [MAS]

pappjo

My eyes went blurry looking at those logs. I did see some like what you're showing occurring earlier today with "scoped", "unable", "failed" or something like that. But later in the logs, I believe after I created the subfolder and restarted, there were none of those error "words".

sjk

Hi, @pappjo.

I still get bug-eyed looking at some of these logs. :)

Since this issue has been resolved for now I'm going to close this topic. Feel free to start a new one if there's anything else we can help you with. Thanks!