Hi Amit
Sure you are busy, thanks for spending time to help...
Unfortunately, this workaround did not work for me.
First, I get a -- sshfs: command not found -- when i try to run the
last command.
Then when I use the -o sftp_server option in MacFusion extra options,
I can mount using the wrapper, but it won't change anything regarding
my permission problem. Tried to play around with the umask value in
the wrapper script but the result is still the exact same.
Looks like it just doesn't change anything anyway.
Would local ACL permissions interfere in anything ?
Any idea ?
Keulu
On 11 fév, 23:19, Amit Singh <[EMAIL PROTECTED]> wrote:
> On Feb 11, 7:55 am, sfy <[EMAIL PROTECTED]> wrote:
>
> >> I have asked this question before in this group, but noone seems to
> >> know or they just don't want to answer it.
>
> Have you considered a third possibility? That people might be really
> busy, etc.?
>
> The "umask" command-line argument that you guys are trying doesn't
> really do what you expect (Yes, some things are unfortunately and
> perhaps even unnecessarily confusing.) The option actually does the
> following in the user-space library for MacFUSE:
>
> if (/* umask argument was specified */) {
> /* Then, while setting OR getting file attributes, make the
> following tweak. */
> statbuffer->st_mode = (statbuffer->st_mode & S_IFMT) | (0777 &
> ~umask));
>
> }
>
> Normally, you shouldn't need to use the umask argument. You'll see
> that with, say, the "loopback" (xmp) file system, your shell setting
> of umask works correctly. With sshfs, it may not work correctly (as is
> the case for you folks).
>
> A big plus of using sshfs is that you don't need anything special on
> the server side beyond typical SFTP access. This also means that sshfs
> is at the mercy of the server's behavior. Unlike NFS etc., where there
> is a dedicated file system server program, sshfs isn't require special
> configuration or behavior. In the umask case, what's happening with
> you folks is that the umask on the server machine (specifically, the
> one that the sftp-server program was run under) is being used. sftp-
> server should behave better, but if it doesn't, there's not much sshfs
> can do in this scenario.
>
> You can work around this by creating a trivial shell script wrapper
> for sftp-server on the server machine. To do this:
>
> * Figure out the path to sftp-server on the server machine. You can
> log onto the machine through ssh, then from another command prompt,
> create an sftp connection to this machine. Then run 'ps' to see which
> sftp-server gets run. On my current Linux box, it's "/usr/lib/openssh/
> sftp-server".
>
> * Somewhere (maybe within your home directory), create a wrapper
> script like the following (make sure it's executable):
>
> #! /bin/sh
> # sftp-server-wrapper.sh
> umask 0
> exec /usr/lib/openssh/sftp-server "$@"
>
> * Now run sshfs and use the "-osftp_server" argument to make sshfs use
> this wrapper script. Something like:
>
> sshfs [EMAIL PROTECTED]:/remote/dir /local/mount/point -osftp_server=/full/
> path/to/sftp-server-wrapper.sh ...
>
> See if your client-side umask setting works as expected now.
>
> Amit
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"macfuse-devel" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/macfuse-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
