After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 535275 - sshfs synchronization uid/gid problem
sshfs synchronization uid/gid problem
Status: RESOLVED WONTFIX
Product: tomboy
Classification: Applications
Component: General
0.10.x
Other All
: Normal normal
: 1.4.0
Assigned To: Tomboy Maintainers
Tomboy Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-05-28 15:39 UTC by Charlie DeTar
Modified: 2014-05-25 02:53 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
tomboy 0.10.2 fix (114 bytes, application/octet-stream)
2009-11-22 05:55 UTC, randomcoder1
Details

Description Charlie DeTar 2008-05-28 15:39:47 UTC
Please describe the problem:
Synchronization using SSH (sshfs FUSE) does not work if the remote server username's UID and GID are different from the local user.  Tomboy is able to connect to the server properly, and mounts the remote directory in ~/.tomboy/sync-sshfs, however with the remote UID and GID, leaving Tomboy potentially unable to syncrhonize notes.



Steps to reproduce:
1. Set up synchronization on a server where the user account has a different UID and GID from the local user.
2. Choose "Synchronize Notes" from "Search All Notes -> Tools" - permissions error will result.
3. Observe that the UID and GID for ~/.tomboy/synch-sshfs match the remote server's UID and GID for the directory owner, and not the local user.


Actual results:
The error is "Error connecting to the synchronization service.  Please try again."  

The logfile (~/.tomboy.log) shows:

fusermount: failed to access mountpoint /home/cfd/.tomboy/sync-sshfs: Permission denied

  at Tomboy.Sync.FuseSyncServiceAddin.MountFuse (Boolean useStoredValues) [0x00000] 
  at Tomboy.Sync.FuseSyncServiceAddin.CreateSyncServer () [0x00000] 
  at Tomboy.Sync.SyncManager.SynchronizationThread () [0x00000] 

The ownership UID/GID of "~/.tomboy/sync-sshfs" matches the remote server's user's UID/GID, not the local user's.

Expected results:
Tomboy should remap the UID of the sshfs mounted directory to use the local user's UID/GID.

Does this happen every time?
yes

Other information:
Passing the "-o uid=?? -o gid=??" options to sshfs results in the expected behavior.  The following results in problematic UID/GID:

sshfs user@server:dir mountpoint

But this results in the correct UID/GID:

sshfs user@server:dir -o uid=`id -u` -o gid=`id -u`
Comment 1 Sandy Armstrong 2008-05-28 15:54:41 UTC
Good catch, should definitely fix this.
Comment 2 Charlie DeTar 2008-05-28 19:33:24 UTC
Correction to above -- the proper sshfs invocation for remapping uid and gid is the following:

sshfs user@server:dir mountpoint -o idmap=user -o uid=`id -u` -o gid=`id -g`

I accidentally said "id -u" twice above, and did not include "idmap=user".  Of course, the invocation from within your C# module may be different, but just wanted to fix myself..

Thanks for looking into it.
Comment 3 Sandy Armstrong 2008-09-14 21:10:06 UTC
I may not have time to test this sufficiently for 0.12.0, but I'd like to get it into an 0.12.x release.  Has anybody else tested/reviewed this patch?
Comment 4 randomcoder1 2009-11-21 10:34:57 UTC
Someone helped me to fix the problem. The root of the problem is sshfs who is responsible for this.
On debian on which I'm ve tested it the problem can be solved by

sudo adduser <tomboy_user> fuse
sg fuse
sshfs spx2@perlmonk.org:/home/spx2/tomboy /home/work/.tomboy/sync-sshfs


sshfs seems to be working ok now and it mounts at the needed location.
I was perviously getting "permission denied" but now it works fine.
otherwise tomboy is a good piece of software :)
Comment 5 Sandy Armstrong 2009-11-21 20:51:04 UTC
Thanks for the tip, randomcoder1.  Sorry for those affected by this bug; have not had time to investigate it.
Comment 6 randomcoder1 2009-11-22 05:55:02 UTC
Created attachment 148257 [details]
tomboy 0.10.2 fix
Comment 7 randomcoder1 2009-11-22 05:56:07 UTC
Hey Sandy! :) to me the whole point of having tomboy is synchronization. If that is poorly working it's pretty bad(IMHO), please invest some time in fixing the problem.

I also get random errors like "Please wait 2 more minutes, one of your other computers is sync-ing" while *I KNOW* the other computer isn't sync-ing...
So I put together a quick fix script for when that happens(attached to this message)...

I'm using this on 2 machines

-Debian , Tomboy 0.10.2 
-Ubuntu , Tomboy 0.14.0
(Why is Debian so far behind ??)

Also I'd like to mention I'm using auth with ssh keys(in tomboy 0.10.2 it would actually expect me to put the passphrase in the terminal each time I wanted to use sshfs ... but I guess this isn't a problem if I upgrade to 0.14.0, and I'm probably going to do that on both machines).

I also wanted to put this on Windows using gtk-sharp from Novell(the one you mention in your download page) , however that gives me an error at about 99% of the install and then it rolls back so I don't get to have gtk-sharp so no Tomboy for me on Windows.

If I could get it to run on Windows it would be fantasticolous(I think you agree). Also would syncrhonization by sshfs work on Windows ? I'm thinking if not, maybe some convoluted design with http://dokan-dev.net/en/download/ ?!?!

Maybe sshfs isn't such a good idea for Windows...

I will probably need to use Unison + Tomboy/Zim to get this done in proper,portable way.

What do you think ?

To what lengths we need to go in order to set up a simple synchronizing 
note-taking system... :)
Comment 8 Sandy Armstrong 2009-11-22 15:22:43 UTC
We are shifting our focus away from the filesystem-based sync backends to web-based sync backends.  The main point is to make sync easier to set up and more compatible on different platforms.

So that's why we've worked hard on a good REST API which is implemented by Snowy (a django web app that will power Tomboy Online) and Ubuntu One.

A few other points:
* Anything earlier than 0.14.2 is known to have sync bugs.  The only release with a data-loss sync bug was 0.12.0, but I'm not surprised you're having issues using 0.10.x and 0.14.0.  I highly recommend upgrading to 1.0.1 if you can.  We maintain a PPA with packages for Ubuntu Jaunty and greater here http://lists.beatniksoftware.com/pipermail/tomboy-list-beatniksoftware.com/2009-September/001352.html
* You're right that we have no SSH sync backend on Windows.  You would have to use the file system sync backend on Windows and set up the SSH mount manually using something like Dokan.
* If you're having issues installing Tomboy on Windows, please file a separate bug and mention what version of Windows you are using and what the error is.
* If you use Tomboy 1.0.1 on all platforms, you have two decent sync alternatives:

1) Use Ubuntu One (since we haven't launched Tomboy Online yet), and the "Tomboy Web" sync backend.
2) Enable the Note Directory Watcher add-in, and sync your Tomboy note directories on all systems using Unison or Dropbox or whatever systm you're comfortable with.  When that add-in is enabled, Tomboy listens for changes to the files in its note directory, so if you update the file on one computer, Tomboy automatically updates the note on the other computers.

Once the Snowy software is more mature, you'll have the option of using Tomboy Online, or running Snowy on your own server if you prefer total control over your data.  Right now Snowy is pre-alpha and I would not recommend running it on a public server (sync works fine, but security is not well-tested yet).

Finally, none of the issues in your latest comment have anything to do with this uid/gid bug.  So if you have any questions or issues, please file new bugs or email tomboy-list, or you can find me in #tomboy on GIMPNet pretty much all day (UTC-8).

Hope this helps! :-)