I tested and if I change the permissions to XX4 I can read the files fine, so this is definitely the problem
On Jun 21, 10:10 pm, Sam <[EMAIL PROTECTED]> wrote: > I think will solve the problem I am having, on folders with XX0permissions, > I can't read them even when logged into the remote > system as root. > > On May 9, 12:00 am, Amit Singh <[EMAIL PROTECTED]> wrote: > > > MacFUSE 0.3.0 can do file permission check in 2 ways: > > > 1. If the user-space file system program (such as sshfs-static, > > curlftpfs, or whatever MacFusion might be using) actually implements a > > permission check method (the "access" method), MacFUSE will call that > > method to see if a given user has access to a given file. > > > 2. If the user-space file system program doesn't implement an "access" > > method, then MacFUSE will let your OS X kernel do permission check. > > However, this relies on the user and group identifiers that are > > reported by the user-space file system. Typically, your "local" user/ > > group identifiers (on the Mac OS X client) are different from those on > > your FTP or SSH server. For things to work correctly, the user-space > > file system must then translate these remote identifiers to match the > > local ones. Since it's not the kernel that's communicating with the > > FTP/SSH servers, the kernel has no idea what the mapping is. If the > > mapping is not there, or is incorrect, the kernel will think you're > > trying to access somebody else's files, and you may get a permission > > error. > > > This leaves us with the case when the user-space file system neither > > implements an "access" method, nor does user/group ID mapping. With > > MacFUSE 0.3.0, if your local user/group ID happens to be different > > from the remote one, you'll get a permission error for files/ > > directories that don't allow the requested access to "others". This > > isn't crazy or a serious problem--this is just how file systems work > > in Mac OS X, or one version of how file systems work. > > > One thing MacFUSE could do is to support an option (MacFUSE already > > has a sickeningly large number of options, many of which end users > > don't/shouldn't have to understand), say, "defer_auth". If this option > > is specified at mount time, you're basically telling MacFUSE that you > > *know* that you have a file system that neither maps user/group IDs, > > nor implements "access". In that case, MacFUSE will provide a dummy in- > > kernel version of access that just returns a 0 always (0 means the > > permission is allowed). In this case, regardless of user/group ID > > differences, file operations will go through, but they will still fail > > (as they should) if you *really* don't have access on the server (that > > is, if your FTP/SSH operation would fail through other FTP/SSH tools, > > it would fail with MacFUSE; if the operation would succeed because you > > really have access on the server, the operation would succeed with > > MacFUSE). This can be thought of as a fallback mechanism. It was sort > > of like this in MacFUSE release before 0.3.0, but there were some > > subtle differences I'm too exhausted to explain at this moment. > > > "defer_auth" will be in the next version of MacFUSE. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
