"fuse: mountpoint is not empty" syncing over ssh

[Alan Pope 🍺🐧🐱 🦄]

Binary package hint: tomboy

Trying to sync over ssh to a remote server and it's erroring with:-

"Error connecting :(
An error ocurred while connecting to the specified server:

fuse: mountpoint isnot empty
fuse: if you are sure this is safe use the 'nonempty' mount option"

I have had syncing working intermittently, but now it refuses to work. I have it working to the same server, same user, same key on another PC, but on this one, it no longer syncs.

15/10/2007 16:42:57 [DEBUG]: Error calling /usr/bin/sshfs

^^ that's all I get in the .tomboy.log

[Andrew Conkling (andrewski)]

Confirmed, same problem.

[Alan Pope 🍺🐧🐱 🦄 (popey)]

The following command seems to allow the sync to be setup again.

alan@mother:~$ fusermount -u ~/.tomboy/sync-sshfs
fusermount: entry for /home/alan/.tomboy/sync-sshfs not found in /etc/mtab

[cdnotorious (chuckempire-gmail)]

I have the same error. Alan's command did not work for me.

[John Carney (john-innercurmudgeon)]

Looks like somebody isn't cleaning up after themselves. I had the same problem and was able to work around it by removing the file named "lock" from ~/.tomboy/sync-sshfs

jcarney@lirazel:~$ rm -f ~/.tomboy/sync-sshfs/lock

[Frederik Elwert (frederik-elwert)]

Hm, I think this may be related: When I try to sync, I get this error in the log and syncing fails:

26.11.2007 01:10:50 [DEBUG]: SyncThread using SyncServiceAddin: SSH (sshfs FUSE)
26.11.2007 01:11:03 [ERROR]: Synchronization failed with the following exception: Access to the path "/home/xxx/.tomboy/sync-sshfs/lock" is denied.
  at System.IO.FileStream..ctor (System.String name, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000]
  at System.IO.FileStream..ctor (System.String name, FileMode mode, FileAccess access, FileShare share) [0x00000]
  at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
  at System.Xml.XmlTextWriter..ctor (System.String filename, System.Text.Encoding encoding) [0x00000]
  at Tomboy.Sync.FileSystemSyncServer.UpdateLockFile (Tomboy.Sync.SyncLockInfo syncLockInfo) [0x00000]
  at Tomboy.Sync.FileSystemSyncServer.BeginSyncTransaction () [0x00000]
  at Tomboy.Sync.SyncManager.SynchronizationThread () [0x00000]

[Andrew Conkling (andrewski)]

John, that worked for me as well.

[Matt Price (matt-price)]

neither fix works for me; on gutsy, with most recent tomboy.

[Michał Świtoń (switon.michal)]

Works for me too John, thanks for help :)

[John Stultz (jstultz)]

The "fusermount -u ~/.tomboy/sync-sshfs" trick works, but only once per sync attempt. The next time I sync it does the same thing again.

From the looks of it, tomboy isn't unmounting the sync dir when its done syncing.

[Daniel James (daniel-netbreeze)]

I'm having this issue as well.. tomboy leaves the sync folder mounted. I have to manually unmount it before I can sync again.

[fnj (fnj666)]

Why is this bug still there in 8.04? It's gotta be a simple case of Tomboy not unmounting the dir when it's done.

[PeterThomas (peter-the-thomases)]

I'm on 8.04 and am having this problem as well. Alan's command to unmount the sshfs dir worked for me. I was poking around in the source and it appears that the output of 'mount' has changed in 8.04 for sshfs mounts. On 7.10 (works fine for me) the mount output line is this:

sshfs#user@host:/path/to/tomboy/notes on /home/user/.tomboy/sync-sshfs type fuse (rw,nosuid,nodev,max_read=65536,user=user)

On 8.04 the mount output line is this:

user@host:/path/to/tomboy/notes on /home/user/.tomboy/sync-sshfs type fuse.sshfs (rw,nosuid,nodev,max_read=65536,user=user)

On line 357 of Tomboy/Synchronization/FuseSyncServiceAddin.cs (SVN Rev 1993) the application depends on the mount output line beginning with the mount command name ('sshfs', works in < 8.04), but in 8.04 this has changed. Snippet:

    if (outputLine.StartsWith (FuseMountExeName) &&
                    outputLine.IndexOf (string.Format ("on {0} ", mountPath)) > -1)
     return true;

This bug has already been submitted in GNOME Bugzilla (http://bugzilla.gnome.org/show_bug.cgi?id=522424)

[Dennis S (dennis-dennisschaaf)]

Alans fix worked for me

[Dennis S (dennis-dennisschaaf)]

I appologize, I posted that prematurely, It worked for me and then on second sync it doesn't work anymore ...

[Andrew Conkling (andrewski)]

On Thu, May 15, 2008 at 12:27 PM, Dennis S <email address hidden> wrote:

> I appologize, I posted that prematurely, It worked for me and then on
> second sync it doesn't work anymore ...

Yeah, it's not a fix, only a workaround.

[Sandy Armstrong (sanfordarmstrong)]

This is fixed in trunk and the 0.10.x branch, and I'll make an 0.10.2 release soon, which will hopefully make its way into Hardy.

In the mean time, if you are affected by this, manually mount your desired share, and then use Tomboy's "Local Folder" sync service and point to the place you mounted it.

[Martin Pitt (pitti)]

Accepted into -proposed, please test and give feedback here

[Dan McCombs (overridex)]

I've been running the package from -proposed on two machines for several days now, and I'm still experiencing some weirdness with it - sometimes it's not mounting the sshfs, and puts the lock file in the local directory, then it can't mount sshfs until that lock file is manually deleted. Also, it doesn't always seem to be removing the lock from from sshfs when it's finished syncing, and it has to be removed manually. Occasionally it's saying that syncing failed though it lists all the notes being updated as well.

I'm not really sure exactly when these symptoms happen, it doesn't seem to be happening when I do anything in particular, but they happen very often. Let me know any other information I can provide and I'll be glad to help.

Thanks,

Dan

[qo_ (imtimt)]

Sanford wrote: ^^^In the mean time, if you are affected by this, manually mount your desired share, and then use Tomboy's "Local Folder" sync service and point to the place you mounted it.^^^

Hmm, I manually mount using wdfs and point Tomboy to the mounted directory, and am seeing this same issue i.e. lock file remaining from the previous sync.

Tomboy 0.10.1, wdfs 1.4.2, Fedora 9.

Mounting using the following:

/usr/bin/wdfs https://myserver.com:2078 /home/me/webdisk -o username=myuser -o password=mypass -o accept_sslcert

I've stumbled upon a workaround though. If you tell FUSE to disable multi-threading ( -s) , Tomboy is able to remove the lock:

/usr/bin/wdfs https://myserver.com:2078 /home/me/webdisk -o username=myuser -o password=mypass -o accept_sslcert -s

Could others give this a try? sshfs also provides a -s option.

Thanks,

qo

[qo_ (imtimt)]

Opps. Sorry. I spoke too soon. Using -s seemed to help in the case where Tomboy is able to sync successfully. But, in cases where the sync fails, the lock is still left behind.

In my case, sync is not completing on the first try when many notes need to be synced. This results in the lock remaining. So, steps are:

1. Start a sync
2. Sync partially completes
3. Manually delete the remote lock on the WebDAV server
4. Start another sync
5. This adds more notes from the server that didn't sync the first time
6. Manually delete the remote lock
7. Repeat steps 4-6 as many times as it takes for all notes to be synced

Now, add ONE new note. Start a sync. It succeeds and the lock is properly removed afterward.

Specifically, if you can get to the point where Tomboy reports:

                       Synchronization is complete
                    8 notes updated. Your notes are now up to date.

Then the lock will likely have been successfully removed.

Also, if Tomboy starts to sync automatically (before you start a manual sync) the lock is not cleaned up. Perhaps this was addressed -proposed (?).

Again, my apologies if anyone's hopes were raised.

qo

[qo_ (imtimt)]

Not sure if anyone is still reading this, but I have a question regarding the lock file format:

Below, what is the <client-id /> tag for? I'm asking since is doesn't seem balanced by a <client-id> tag (I'm no XML wiz...).

What is this used for? Maybe I'm way off base but could imagine that if client-id = us, then we could safely remove the lock and proceed with the transaction. But, this tag doesn't seem to have a value associated with it, so I can't understand what use it has(?).

<?xml version="1.0" encoding="utf-8"?>
<lock>
  <transaction-id>46738997-c2b7-4838-b4d9-eb4da537432f</transaction-id>
  <client-id />
  <renew-count>9</renew-count>
  <lock-expiration-duration>00:02:00</lock-expiration-duration>
  <revision>10</revision>
</lock>

Thanks,

qo

[Sandy Armstrong (sanfordarmstrong)]

qo: Good detective work. client-id is supposed to be a GUID identifying the system that "owns" the lock on the sync server. The fact that yours is empty could be a problem, as (maybe) your system keeps getting confused that when it sets a lock, it looks like it was made by a *different* system (because the GUIDs don't match).

I'll look into this as soon as I can.

By the way, <client-id /> is equivalent XML to <client-id></client-id>, so no worries there.

Thanks again for info!

[Dan McCombs (overridex)]

My <client-id /> tag is empty as well, every time I sync it says another computer is using it and I have to remove it manually (it doesn't seem to get deleted when the sync is completed) plus the other issues I mentioned in my last comment...

Dan

[qo_ (imtimt)]

Thanks, Sanford, for all your great work on Tomboy, and for the mini-tutorial on XML :-)

regards,

qo

[Onkar Shinde (onkarshinde)]

I just tried the packages from hardy-proposed on my hardy installation.
It works first time. Then it says I have to wait for 2 minutes. I see a lock file in my ~/.tomboy/sync-sshfs as follows.

<U+FEFF><?xml version="1.0" encoding="utf-8"?>
<lock>
  <transaction-id>1c5caa03-ebd5-4847-be15-1c307904201e</transaction-id>
  <client-id />
  <renew-count>0</renew-count>
  <lock-expiration-duration>00:02:00</lock-expiration-duration>
  <revision>1</revision>
</lock>

I removed the lock file and synced again.
But I am still getting lock file intermittently. Sometimes when I leave tomboy idle, sometimes when I restart it, sometime when I modify a note.
I have also observed that the modified date of lock file is getting updated every minute so the lock never expires.

I am not sure how much my analysis is correct and reproducible because I did only in 15-20 minutes. Hope it helps.

[nine (niin-deactivatedaccount-deactivatedaccount)]

For me 0.10.2-0ubuntu1 (currently in hardy-proposed) solves the problem. Destination host was Intrepid.

[Steve Langasek (vorlon)]

based on the feedback here, it appears that the package currently in -proposed includes a necessary, but not sufficient, fix for this bug. I'm going ahead with publishing this version to hardy-updates for the 8.04.1 point release, but leaving this bug open for tracking of possible further fixes.

[Zsolt Zakál (zakalzs)]

The bug is still exist in the current version :(

Tomboy 0.10.2
0.10.2-0ubuntu1

[Sean Hodges (seanhodges)]

Upstream bug:

http://bugzilla.gnome.org/show_bug.cgi?id=522424

Seems Intrepid is at version 0.11.0 right now. Can anyone confirm if this bug is fixed in a later version? I'm also still experiencing it in 0.10.2-0ubuntu1.

[Zsolt Zakál (zakalzs)]

0.11 (from GetDeb.net) has the same bug.

[Andrew Conkling (andrewski)]

On Fri, Jul 11, 2008 at 06:51, Zsolt Zakál <email address hidden> wrote:

> 0.11 (from GetDeb.net) has the same bug.

The upstream bug hasn't been fixed; this won't be fixed for 0.11. It was
only (supposedly) fixed for Ubuntu's package, 0.10.2-0ubuntu1, but I suspect
that isn't the case either.

[Sandy Armstrong (sanfordarmstrong)]

Okay, I'm finally looking into the remaining sync issues and anybody experiencing problems should watch this upstream bug:

http://bugzilla.gnome.org/show_bug.cgi?id=535279

Preliminary investigation shows that lock files are not being handled correctly at all. Thanks for all of your reports and help, Ubuntu folks. I apologize for the many delays.

[Sean Hodges (seanhodges)]

Thats great news Sanford, thanks for the update.

To maintainers: assuming the bug is fixed in reasonable time, is this likely to make the Intrepid beta freeze on the 25th?

[Sandy Armstrong (sanfordarmstrong)]

Sean, since Tomboy is part of GNOME, and Ubuntu is just following our release cycle, the answer to your question is "yes".

I'm committing fixes upstream as we speak, and there will be a release on the 22nd.

[Andrew Conkling (andrewski)]

On Mon, Sep 15, 2008 at 9:01 AM, Sean Hodges <email address hidden>wrote:

> To maintainers: assuming the bug is fixed in reasonable time, is this
> likely to make the Intrepid beta freeze on the 25th?

Correct me if I'm wrong, but I believe the question here is whether these
fixes will make it into upstream Tomboy in time (which is subject to GNOME's
own 2.24 freezes).

[Paul McEnery (pmcenery)]

I downloaded the source package for the version that comes with hardy, replaced the source with 0.12.0 and recompiled. Synchronisation is _much_ better now. I havent had any lock issues.

Thanks Sandy. Works a treat so far!

Sorry no package for everyone else. I dont have a proper build environment setup... Hopefully one finds its way into Hardy soon.

[Martin Pitt (pitti)]

Feedback here is unclear, but there is no currently pending SRU, nor a proposed patch, thus I reset the bug status and unsubscribe ubuntu-sru. If you still have problems with the current hardy-updates version, or with intrepid, pleaes report back here, otherwise please close the bug. Thank you!

[Henrik Nilsen Omma (henrik)]

We pulled in the first Gnome bug-fix release before Intrepid final which should have included the fix Sandy committed. Please reopen if this is still a problem in Jaunty.

[Greg Grossmeier (greg.grossmeier)]

Setting the tomboy (Ubuntu) task to Fix Released as there have been no other reports of this issue (and the Hardy task is marked as Fix Released).

[Andy Buckley (andy-insectnation)]

Can this fix be backported to Hardy, preferably the latest 0.12 version if there are no dependency problems? I'm still seeing a stuck lock file in Hardy (0.10.2-0u1 - http://packages.ubuntu.com/hardy-updates/tomboy), and since Hardy is an LTS release that means having to manually clear the lock for one more year unless it's updated!

[Invincicble Mutant (ngkengyap)]

Just found the bug, but i am not a good cs programmer to debug this. But I think i can point out the root cause of this problem.

This note is on Tomboy 1.2.1

Apparently when you are trying create an sshfs sync, tomboy create a lock file in the following folder

~/.cache/tomboy

This lock file is not duly deleted upon sshfs mounting failure. If you have been caught with mounting failure such as mounting with wrong credential or an denied folder on the server, the lock file will be retained in that folder. You will then get mount is not empty error.

Manually remove the lock file will do the job until you can successfully mount the remote folder.
rm -r ~/.cache/tomboy/lock

Goog luck.

[b (ben-ekran)]

I'm having this problem in lucid.

I can't believe it was a problem back in hardy.

At least manually removing the lock seems to work.

[Beowulf (s-highlander)]

I have the same problem in Ubuntu 12.10