Can't save files any more since .3

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Hook up via sshfs
2. Open file with TextMate
3. Try to save

What is the expected output? What do you see instead?

The file should just get saved.

Instead, a dialog comes up asking for my password.  I type it in, TextMate 
beeps and doesn't 
save the file.

This occurrs with -o idmap set to either none or user.  Previous version just 
worked and there's a 
note about User and group ID mapping is now turned on by default so that's the 
setting I tried 
playing with to no avail.

What version of the product are you using? On what operating system?

0.3.0, OS X Intel, 10.4.9

Original issue reported on code.google.com by sstein...@gmail.com on 10 May 2007 at 5:25

[GoogleCodeExporter]

Just verifying that I'm using the latest as per the other defect posted about 
this issue:

BiggerMac-2:~ ssteiner$ sshfs --version
SSHFS version 1.7 (MacFUSE, 10, May  4 2007, 15:04:35)
FUSE library version: 2.6.5
MacFUSE version 0.3.0
using FUSE kernel interface version 7.8

Original comment by sstein...@gmail.com on 10 May 2007 at 5:29

[GoogleCodeExporter]

Also confirming that I downloaded directly from this site.

Original comment by sstein...@gmail.com on 10 May 2007 at 5:30

[GoogleCodeExporter]

Which sshfs are you using specifically? By "0.3.0", do you mean just MacFUSE 
0.3.0 or do you mean both 
MacFUSE 0.3.0 and sshfs 0.3.0? What does "sshfs-static --version" say for you? 
sshfs-static is the actual 
command-line binary that implements the file SSH file system. You can find it 
within the Resources folder of the 
sshfs.app bundle.

Original comment by si...@gmail.com on 10 May 2007 at 5:30

[GoogleCodeExporter]

OK, either you answered my question before I asked it or I simply didn't see 
your response earlier.

Original comment by si...@gmail.com on 10 May 2007 at 5:31

[GoogleCodeExporter]

If you use the most recent sshfs-static, you shouldn't have to play with the 
"idmap" argument. Can you run 
the sshfs command-line program (the one whose version output you showed above) 
as follows:

$ sshfs user@host:/some/remote/path /some/local/path/ -d

"-d" would run it foregrounded in the Terminal, with debugging output being 
printed.

Then, from the Terminal still, try to create a file in the mounted volume:

$ touch /some/local/path/file.txt

Then see what debugging output is printed after you type the "touch" command.

Original comment by si...@gmail.com on 10 May 2007 at 5:35

[GoogleCodeExporter]

I was typing a reply to this message and my computer froze solid.

I had to power cycle and it is now working.

I had rebooted after installing the MacFUSE core, but not after reinstalling 
sshfs.

Very strange but I am now getting the expected behaviour.  

Thanks, S.

Original comment by sstein...@gmail.com on 10 May 2007 at 8:26

[GoogleCodeExporter]

I spoke too soon...

Even though I'm logging in as root, I'm not given root priviliges on the server 
and can't edit any files in any user's 
directory.

Original comment by sstein...@gmail.com on 10 May 2007 at 8:39

[GoogleCodeExporter]

No root privileges with idmap as none, no privs with idmap as user.

This is definitely different from the previous behaviour -- I have been using 
this tool since it came out and have 
never experienced this.

Original comment by sstein...@gmail.com on 10 May 2007 at 9:15

[GoogleCodeExporter]

No root privileges with idmap as none, no privs with idmap as user.

This is definitely different from the previous behaviour -- I have been using 
this tool since it came out and have 
never experienced this.

When logging in as a specific user, I am able to access their files.

Original comment by sstein...@gmail.com on 10 May 2007 at 9:17

[GoogleCodeExporter]

No root privileges with idmap as none, no privs with idmap as user.

This is definitely different from the previous behaviour -- I have been using 
this tool since it came out and have 
never experienced this.

When logging in as a specific user, I am able to access their files.

Original comment by sstein...@gmail.com on 10 May 2007 at 9:33

[GoogleCodeExporter]

The behavior *is* different because it was meant to be that way--it's not an 
accident. It's not very confusing if 
you don't extrapolate previous behavior and judge based on that as to what's 
happening. Points being:

1. On a local machine, MacFUSE will NOT (and did not, even earlier) let you 
access a volume unless you are the 
user that mounted the volume. This blanket permission denial has nothing to do 
with what uid/gid the remote 
(SSH/FTP etc.) mount is showing.

2. In particular, the blanket denial applies to the root user too. Even if you 
are root, you can't enter a MacFUSE 
volume unless you mounted it as root. Otherwise, it would make it easier for a 
user space file system to hang/
mislead any root owned system processes that happen to encounter the volume. 
This behavior has always 
been like this and is an architectural decision.

3. Regardless, you can still unmount a volume as root.

4. You can disable the blanket denial by passing the "allow_other" mount-time 
option.

5. For MacFUSE 0.3.0 specific permission changes, read the following thread:

http://groups.google.com/group/macfuse-devel/browse_thread/thread/8ddca0a74765f2
00

Original comment by si...@gmail.com on 10 May 2007 at 11:45

[GoogleCodeExporter]

At a glance, this is remarkably similar to an issue reported by a user of 
MacFusion. I will cross-reference for 
consideration.

Original comment by grahampe...@gmail.com on 12 May 2007 at 10:14

[GoogleCodeExporter]

<http://groups.google.com/group/MacFusion-devel/browse_frm/thread/5a1e3d5fffabfa
0c> post #5 from me 
to MacFusion-devel should reach DrieSstone who reported similar symptoms. 

Not sure how similar; DrieStone had success saving with BBEdit after 
authentication whereas here for ssteinerx 

> TextMate beeps and doesn't save

Original comment by grahampe...@gmail.com on 12 May 2007 at 10:46

[GoogleCodeExporter]

I hope people are well aware of the MacFUSE permissions model now.

Original comment by si...@gmail.com on 29 May 2007 at 7:21

• Changed state: Invalid