search

fluiday / macfuse

Automatically exported from code.google.com/p/macfuse
Other
0 stars 0 forks source link

cannot copy to ssh volume ndrive.uscs.susx.ac.uk (lapwing.uscs.susx.ac.uk) (139.184.228.15) #155

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Finder attempts to copy files, such as a simple 4 KB text file, result in the 
following error: 

> The operation cannot be completed because 
> one or more required items cannot be found. 
> (Error code -43).

A Cyberduck view of the destination, whilst that error remains in Finder, 
reveals that alongside
test.txt
(which seems to be properly written; I can read that file using Cyberduck)
there is a dot underscore file 
._test.txt

After I acknowledge error -43 in Finder, both 
test.txt 
and
._test.txt 
are removed from the destination. 

As the affected volume is primary storage for users of Windows PCs on our 
campus, in this 
context the bug might be described as an sshfs show-stopper. 

That said, I do appreciate that 
sshfs.app is not a supported product :-)

Environment
-----------

sshfs.app 0.2.0
MacFUSE 0.2.5

ndrive.uscs.susx.ac.uk (lapwing.uscs.susx.ac.uk) (139.184.228.15)
connected via ssh as gjp22 to path 
/IBIS/HOME1/gjp22

Regards
Graham

Original issue reported on code.google.com by grahampe...@gmail.com on 27 Apr 2007 at 3:45

Attachments:

GoogleCodeExporter commented 9 years ago 
What happens if you do the same copy from the command line?

Original comment by si...@gmail.com on 27 Apr 2007 at 7:33

GoogleCodeExporter commented 9 years ago 
When you see this error, do you see any messages in /var/log/system.log?

Original comment by si...@gmail.com on 27 Apr 2007 at 7:39

GoogleCodeExporter commented 9 years ago 
I'm struck by the privileges with which the volume is mounted. I authenticate 
as gjp22 but the entry at 
/Volumes
has a different owner: 

drwx------     1 gjp22  111    2048 Apr 27 04:18 keeler
drwxrwxrwx     1 32952  wheel     0 Feb  7  2006 ndrive
drwxr-xr-x     1 gjp22  staff  2142 Mar  6 18:57 omnium-gjp22

so it's not surprising that I (gjp22) can not write!

I'm fairly certain that an earlier combination of MacFUSE and sshfs-static were 
not subject to this problem. If 
security in MacFUSE has been tightened (I'm thinking of allow_root and 
allow_other) this would make sense. 

I wonder whether this issue is peculiar to Novell's implementation? (See below.)

I'll do some digging, report back. 

Regards
Graham

Background
----------

Re <https://rt.sussex.ac.uk/Ticket/Display.html?id=4745#txn-82540> within our 
internal request tracking 
system, in September 2006 a colleague wrote: 

> ... sftp service mapping available directories during the
> authentication process. 

> Specify a path during the connection may simply be the wrong thing
> to do with Novell's implementation of this service. It's definitely
> the wrong thing to do in general since neither the server name (e.g.
> USCSHOME2) nor the volume name (e.g. HOME1) are immutable, and will
> be changed without alerting/consulting users, especially in a
> clustered context.

Elsewhere, around the same time, a colleague wrote: 

> ... it's just the presentation of POSIX rights through the FTP and
> SFTP 

> ... mapping of Users' N Drive filespaces, within the virtual file
> system, visible under FTP and SFTP.

Original comment by grahampe...@gmail.com on 27 Apr 2007 at 4:00

GoogleCodeExporter commented 9 years ago 
grahamperrin:

No, there have been no permissions/security related changes to MacFUSE for a 
while--at least none that I can 
remember and would be relevant to the scenario you described.

Actually, if you are successfully logged in (have mounted the sshfs volume), 
the uid/gid that you see for files 
within the volume don't affect the blanket permission denial. It works like 
this:

* On your local Mac client, suppose you have uid U and gid G.
* When you mount an sshfs volume, MacFUSE will record the uid/gid of the 
process that mounted the volume; 
if there were no funky setuid/setgid calls, these would still be U and G.
* In many cases, the uid/gid that you see for files within the sshfs volume 
will *not* be U/G because the 
remote server has its own uid/gid assignment that's unrelated to your local 
machine's; this is why you're 
seeing 32952 as the uid of your volume's topmost folder. You can make it a bit 
nicer to look at by using the "-
ouid=U -ogid=G" options to sshfs, so sshfs will translate 32952 to the local 
uid of gjp22, so you'll then see 
'gjp22' instead of the numeric uid.

The Finder is known to have some similar sounding issues (file copy fails with 
-43 error) on "network" file 
systems. Try a Google search.

Original comment by si...@gmail.com on 27 Apr 2007 at 4:16

GoogleCodeExporter commented 9 years ago 
OK - that makes sense - and by coincidence was just reading

    -o idmap=TYPE          user/group ID mapping, possible types are:
             none             no translation of the ID space (default)
             user             only translate UID of connecting user

amongst SSHFS options.

Original comment by grahampe...@gmail.com on 27 Apr 2007 at 4:33

GoogleCodeExporter commented 9 years ago 
I experimented with command line options and whilst I gained what *appeared* to 
be appropriate privileges to 
the affected server, I still encountered the -43 error in Finder. 

I'll do some Google searching. 

I have also raised <http://code.google.com/p/macfusion/issues/detail?id=17> as 
a feature request under the 
MacFusion umbrella.

Original comment by grahampe...@gmail.com on 27 Apr 2007 at 5:31

GoogleCodeExporter commented 9 years ago 
grahamperrin:

By "try this on the command line", I meant try doing the copy from the command 
line (in the Terminal, etc., not 
in the Finder).

Original comment by si...@gmail.com on 27 Apr 2007 at 7:32

GoogleCodeExporter commented 9 years ago 
Was refiled as issue #159.

Original comment by si...@gmail.com on 27 Apr 2007 at 9:45

GoogleCodeExporter commented 9 years ago

Original comment by si...@gmail.com on 27 Apr 2007 at 9:46

GoogleCodeExporter commented 9 years ago 
Above at <http://code.google.com/p/macfuse/issues/detail?id=155#c3> I wrote: 

> I'm fairly certain that an earlier combination of MacFUSE and
> sshfs-static were not subject to this problem.

For reference only, tidying my own thoughts ... I was recalling 
<http://code.google.com/p/macfuse/issues/
detail?id=113#c20> when I copied to two servers, one of which was omnium, using 
Finder. The other 
server ... might have been ndrive, might have been keeler (to use their 
familiar names). Now, I wish that I'd 
been more explicit! In any case under 
<http://code.google.com/p/macfuse/issues/detail?id=159> we're 
close to making sense of the oddities with ndrive.

Original comment by grahampe...@gmail.com on 28 Apr 2007 at 11:48