similar to: [Bug 1953] New: Implementation of xattr in sftp-server for sshfs

https://bugzilla.mindrot.org/show_bug.cgi?id=1942 Bug #: 1942 Summary: mounting home directory with sshfs -o reconnect requires patch for ssh Classification: Unclassified Product: Portable OpenSSH Version: 5.8p1 Platform: All OS/Version: Linux Status: NEW Severity: enhancement

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 --- Comment #3 from Christoph Anton Mitterer <calestyo at scientia.net> --- Does anyone know whether anything is going on with SFTP (especially also with repsect to ACLs and XATTRs)? More than a year ago we saw this http://tools.ietf.org/html/draft-moonesamy-secsh-filexfer-00 which apparently tried to restart the draft-ietf-secsh-filexfer

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 Stef Bon <stefbon at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefbon at gmail.com --- Comment #5 from Stef Bon <stefbon at gmail.com> --- I agree with others: xattr support

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 TJ Saunders <tj at castaglia.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tj at castaglia.org --- Comment #6 from TJ Saunders <tj at castaglia.org> --- Instead of using custom SFTP

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 Christoph Anton Mitterer <calestyo at scientia.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |calestyo at scientia.net --- Comment #2 from Christoph Anton Mitterer <calestyo at

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 --- Comment #9 from Christoph Anton Mitterer <calestyo at scientia.net> --- Especially since Eberhard's patch doesn't them *that* intrusive to other parts of openssh, wouldn't simply be possible to use something like RFC 2389,... so server and client could negotiate whether things beyond the basic features are supported and

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 TomH <Tom at TomHolbrook.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Tom at TomHolbrook.co.uk --- Comment #4 from TomH <Tom at TomHolbrook.co.uk> --- Just adding that the lack of

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Damien Miller <djm at

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 --- Comment #8 from Christoph Anton Mitterer <calestyo at scientia.net> --- What a pity... it seemed to be something quite useful for many cases. AFAIU, the only reason not to support it was staying at the base level of the sftp "standard"... however, OpenSSH goes in so many places way beyond the standards... -- You are

https://bugzilla.mindrot.org/show_bug.cgi?id=1953 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #10 from Damien Miller <djm at mindrot.org> --- Close all resolved bugs after 7.3p1 release

What to try: $ cd /tmp $ touch a b $ sftp localhost sftp> cd /tmp sftp> rename a b Couldn't rename file "/tmp/a" to "/tmp/b": Failure sftp> rm b Removing /var/tmp/b sftp> rename a b sftp> So, the sftp "rename" command refuses to rename a file to an existing one. Instead of using the rename(2) system call, which is present at least on

I am using sshfs with FUSE to mount a remote directory over ssh/sftp (on linux). It would be nice if df could be able to show the total size/free space of the mounted directory. I am aware that returning size/free space would have some limitations. For example, if a subdir of the mounted directory has another filesystem mounted on the remote server, this can not be represented simply. However,

Hello, I am investigating a data-loss bug in SSHFS (https://github.com/libfuse/sshfs/issues/72). While the root cause is in SSHFS and has already been fixed, there seems to be some unfortunate interaction with what I believe is an OpenSSH bug: As far as I can tell, when sending a SSH_FXP_OPEN request with SSH_FXF_WRITE (i.e., opening the file write only), and then following up with a

Hello, I've gathered from searching Bugzilla[1][2] that a patch to update OpenSSH's SFTP implementation to support version 4 or above of the protocol is unlikely to be accepted. However, I find myself wishing for the name-based owner and group handling specified in version 4 of the spec[3]. As a possible compromise, if I submitted a patch to add an OpenSSH-specific extension to return

http://bugzilla.mindrot.org/show_bug.cgi?id=1286 Summary: SFTP keeps reading input until it runs out of buffer space Product: Portable OpenSSH Version: v4.5p1 Platform: All OS/Version: Linux Status: NEW Keywords: patch Severity: normal Priority: P2 Component: sftp

Hello, Renaming a file via sftp on an sshfs mount resulted in a failure with errorcode 38 (ENOSYS). This is reproducable with openssh release 4.9p1 & 5.1p1 in combination sshfs 2.2 (latest releases). Investigation revealed that sshfs only implements the rename()-call and not the link()-call (used by sftp-server). Attached is a patch to perform the rename()-call upon a failed link(). The

Hello, This is probably a long email, but please bear with me. I plan to submit a patch and would like to explain what I will do before doing it so I don't lose time if there's some flaw in my plan. I currently use sshfs to mount directories from some computers and a NAS into other computers. I recently noticed that when copying some files from one computer into one of these sshfs

Hi David, I'm sure loginfailed(..) should be called immediately after authenticate(..) returned an error. It is directly related to an invalid password try. (Please see my attached mail from May 2001 to the list). I'm not so sure when loginsuccess(..) should be called (setting the loginfailed counter to zero): Either 1) when somebody logs in successfully using all kinds of valid

We do have exactly the same problem. Is this already solved? cheers Reimar >Running SuSE 9.2. This problem happens with both the SuSE-supplied Samba on >the DVD, as well as the SuSE update rpms to 3.0.9. We even removed all the >*.tdb files and recreated the installation from scratch, as always carefully >following the steps in S3BE. FWIW, this same config worked previously on

Dear all We are using a definition of rules which has perfectly worked with SuSE8.2 and vmware and a local samba on some clients. The systems got an update to 9.2. Now we got a very strange problem which probably could belong to an firewall definition problem. After booting of the system the samba connection to vmware works perfect but a few hours later it isn''t possible to copy a