UbuntuOne.app on OSX cannot connect

Hi Bojan, this sounds like the syncdaemon process is not starting up correctly. If you could please quit all processes starting with 'ubuntuone' (the easiest way to do this is reboot, or you could look in Activity Monitor), and upgrade to the currently shipping version (4.0.1, from https://one.ubuntu.com/downloads/mac/ ), and check whether or not the issue still happens for you, that would be helpful.

If you still have this problem, the best way to debug it would be by looking at the syncdaemon logs in ~/Library/Caches/ubuntuone/log/syncdaemon.log* - those do contain un-anonymized filenames, though, so if you'd rather keep that information private, contacting support via https://one.ubuntu.com/help/contact/ is a good way to do that.

Also for future reference, u1sdtool is packaged inside the app bundle.
Running it from there, eg:
Ubuntu\ One.app/Contents/Resources/U1SDTool.app/Contents/MacOS/u1sdtool --help
should work fine.

Thanks, and I hope this is useful.

Hi Mike.

I have already tried to kill all processes and restart U1 mostly by "ps aux | grep python" and "ps aux | grep Ubu" and manually killing those that look Ubuntu One related. Could I have missed some executable? It didn't work and neither did rebooting tho. It's the same when I restart the app.

I didn't know what to do with the u1sdtool app. I tried copying the bundle to Applications and copying the executable from within to /usr/bin and in both cases it throws error that it can't find python. I can't recall if I tried to run it in terminal from within the app bundle.

I will try with the new version and report back to this bug.

Got the new version. Same old, same old. I also tried moving my Ubuntu One dir and still the same (I still don't know where it keeps the data tho).

Here is the status info from "u1sdtool -s" after I enter my email/passwod:

State: READY
    connection: Not User With Network
    description: ready to connect
    is_connected: False
    is_error: False
    is_online: False
    queues: WORKING

Listing folders and shares shows it's got old sync folders and shares in it's settings.

Here is dump of the syncdaemon log. I removed folder hashing (since it's lots of useless info that potentially reveals private data). From it I concur that it gets empty credentials, regardless of what I enter. It's probably either communication with Ubuntu SSO, or a bug in the UI where I enter the email pass:

2013-03-19 22:41:43,504 - ubuntuone.SyncDaemon.platform.filesystem_notifications.monitor - DEBUG - File monitor ids for platform "darwin" are "{'default': <class 'ubuntuone.platform.filesystem_notifications.monitor.darwin.fsevents_daemon.FilesystemMonitor'>, 'macfsevents': <class 'ubuntuone.platform.filesystem_notifications.monitor.common.FilesystemMonitor'>}"
2013-03-19 22:41:43,504 - ubuntuone.SyncDaemon.platform.filesystem_notifications.monitor - DEBUG - Checking availability of monitor class <class 'ubuntuone.platform.filesystem_notifications.monitor.darwin.fsevents_daemon.FilesystemMonitor'>
2013-03-19 22:41:43,618 - ubuntuone.SyncDaemon.platform.filesystem_notifications.monitor - DEBUG - Monitor is available, returning monitor with id "default"
2013-03-19 22:41:43,619 - ubuntuone.SyncDaemon.Main - INFO - Starting Ubuntu One client version 0.1
2013-03-19 22:41:43,619 - ubuntuone.SyncDaemon.Main - INFO - Using '/Users/bmarkovic/Ubuntu One' as root dir
2013-03-19 22:41:43,619 - ubuntuone.SyncDaemon.Main - INFO - Using '/Users/bmarkovic/Library/Application Support/ubuntuone/syncdaemon' as data dir
2013-03-19 22:41:43,619 - ubuntuone.SyncDaemon.Main - INFO - Using '/Users/bmarkovic/Library/Application Support/ubuntuone/shares' as shares root dir
2013-03-19 22:41:43,619 - ubuntuone.SyncDaemon.tritcask - INFO - Initializing Tritcask on: /Users/bmarkovic/Library/Application Support/ubuntuone/syncdaemon/tritcask
2013-03-19 22:41:43,619 - ubuntuone.SyncDaemon.tritcask - DEBUG - lookingup data files
2013-03-19 22:41:43,697 - ubuntuone.SyncDaemon.tritcask - INFO - found 4 data files, 0 dead and 0 broken files
2013-03-19 22:41:43,697 - ubuntuone.SyncDaemon.tritcask - DEBUG - building the keydir, using: ['1363169892397421', '1362595873057724', '1362595875438018', '1363205370127073']
2013-03-19 22:41:43,697 - ubuntuone.SyncDaemon.tritcask - DEBUG - loading entries from hint of: /Users/bmarkovic/Library/Application Support/ubuntuone/syncdaemon/tritcask/1362595873057724.inactive.tritcask-v1.data
2013-03-19 22:41:44,086 - ubuntuone.SyncDaemon.tritcask - DEBUG - loading entries from hint of: /Users/bmarkovic/Library/Application Support/ubuntuone/syncdaemon/tritcask/1362595875438018.inactive.tritcask-v1.data
2013-03-19 22:41:44,183 - ubuntuone.SyncDaemon.tritcask - DEBUG - loading entries from hint of: /Users/bmarkovic/Library/Application Support/ubuntuone/syncdaemon/tritc...

Hi Bojan, I'm sorry that upgrading didn't fix things for you. Indeed it looks like there's a problem with getting the correct credentials. There are other logs that would be useful to look at. Would you mind running the script here:

http://bazaar.launchpad.net/~mikemc/+junk/mac-client-support-scripts/view/head:/mac-logs.command

and sending the resulting archive to us in a support request?

Or, if you'd prefer to continue this via this bug report, please attach the contents of ~/Library/Caches/sso/sso-client.log
(There are potentially several log files there, as they are rolled over when the app restarts. Ideally you could reproduce the bug just before sending the most recent log, to be sure we have a log file that shows the problem.)

To answer one of your questions, the folder ~/Ubuntu One/ just contains your files - the app stores your metadata in ~/Library/Application Support/ubuntuone/

However, as you correctly guessed, it looks like a credentials issue.

Also, you're right that the u1sdtool program is meant to be run from inside the app bundle, just as in the example I wrote above. It has hard-coded paths to libraries that are included in the bundle, and won't work if you copy it elsewhere.

Hello,

I've made the logs.zip using the script you link to. I'm going to backup my U1 metadata folder to try a "clean reboot" of U1 on this machine. If it works I will substitute it with the backed-up "wrong" copy if you need to hunt the bug down further, but now I need my U1 functionality back.

On 20. 3. 2013., at 18:14, Mike McCracken <email address hidden> wrote:

> http://bazaar.launchpad.net/~mikemc/+junk/mac-client-support-
> scripts/view/head:/mac-logs.command

Hello,

I'd just like to bump this. Unfortunately, removing all Ubuntu One folders and reinstalling as per your instructions above and here: http://askubuntu.com/a/233097/104707 did not help. It seems to remain broken stubbornly. So if a kind soul could check out my logs and has a suggestion I'm all ears.

I have the same issue. I have the ubuntu one support ticket #38054

With a lot of fiddling and restarting, I was able to get logged in and sync files in the Ubuntu One folder. However, I cannot sync my documents folder. When I click the check box to "Sync locally" I get an endless wait with "Getting information, please wait..." I have Mac OS 10.8.5 on a MacBook Pro.

Bojan, there are crashes in your log that look like a bug that has been fixed for the next release but hasn't been released.
Here is a link to the disk image for the next release - this will almost certainly be the exact same file that
will be part of the official release, so it's safe to just use as if you downloaded it from the site.

http://ubuntuone.com/0y69BvJyhg16UyYF4X1XGg

Kevin, could you please file a support request here: https://one.ubuntu.com/help/contact/
Bug comments are not the best place to track this kind of issue.

It would speed things up if you also attach log files to the support request, using these steps:

1. Download http://bazaar.launchpad.net/~mikemc/+junk/mac-client-support-scripts/download/head:/maclogs.dmg-20121003182446-k6qae0iovjpimqy1-1/mac-logs.dmg

2. Mount the image, and double-click the mac-logs.command file inside. This will create a ZIP file called logs.zip on your Desktop which contains your log files, and will open a Finder window with the new file highlighted.
(NOTE: this file will potentially contain the names of some of your files, but will not contain any file contents or your username or password.)

3. send the ZIP file created in step 2.