You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(19) |
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(32) |
Feb
(34) |
Mar
(54) |
Apr
(29) |
May
(21) |
Jun
(17) |
Jul
(12) |
Aug
(32) |
Sep
(32) |
Oct
(26) |
Nov
(53) |
Dec
(37) |
2007 |
Jan
(14) |
Feb
(19) |
Mar
(30) |
Apr
(20) |
May
(33) |
Jun
(8) |
Jul
(6) |
Aug
(26) |
Sep
(30) |
Oct
(25) |
Nov
(20) |
Dec
(24) |
2008 |
Jan
(14) |
Feb
|
Mar
(30) |
Apr
(23) |
May
(25) |
Jun
(9) |
Jul
(21) |
Aug
(18) |
Sep
(19) |
Oct
(40) |
Nov
(17) |
Dec
(6) |
2009 |
Jan
(33) |
Feb
(22) |
Mar
(14) |
Apr
(14) |
May
(4) |
Jun
(6) |
Jul
(9) |
Aug
(8) |
Sep
(5) |
Oct
(6) |
Nov
(18) |
Dec
(3) |
2010 |
Jan
(6) |
Feb
(9) |
Mar
(4) |
Apr
(11) |
May
(6) |
Jun
(23) |
Jul
(8) |
Aug
(6) |
Sep
(6) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
2011 |
Jan
(8) |
Feb
(18) |
Mar
(6) |
Apr
(8) |
May
(8) |
Jun
(5) |
Jul
(17) |
Aug
(2) |
Sep
(6) |
Oct
(23) |
Nov
(13) |
Dec
(27) |
2012 |
Jan
(13) |
Feb
(34) |
Mar
(14) |
Apr
(10) |
May
(2) |
Jun
(5) |
Jul
(10) |
Aug
(2) |
Sep
(8) |
Oct
(6) |
Nov
(3) |
Dec
(1) |
2013 |
Jan
(2) |
Feb
(22) |
Mar
(4) |
Apr
|
May
(2) |
Jun
(2) |
Jul
(6) |
Aug
(4) |
Sep
(4) |
Oct
(5) |
Nov
(1) |
Dec
(11) |
2014 |
Jan
(9) |
Feb
(4) |
Mar
(3) |
Apr
(4) |
May
(5) |
Jun
(2) |
Jul
(6) |
Aug
(2) |
Sep
(2) |
Oct
(6) |
Nov
(2) |
Dec
(1) |
2015 |
Jan
(1) |
Feb
(2) |
Mar
(11) |
Apr
(4) |
May
(3) |
Jun
(3) |
Jul
(1) |
Aug
(10) |
Sep
|
Oct
|
Nov
(4) |
Dec
(4) |
2016 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(7) |
Aug
(6) |
Sep
(5) |
Oct
(8) |
Nov
(7) |
Dec
(4) |
2018 |
Jan
(15) |
Feb
(20) |
Mar
(24) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
(3) |
Aug
(1) |
Sep
(4) |
Oct
(2) |
Nov
|
Dec
(11) |
2019 |
Jan
|
Feb
(4) |
Mar
|
Apr
(5) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(6) |
Nov
(3) |
Dec
|
2020 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(1) |
Dec
|
2021 |
Jan
(6) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(6) |
Dec
(2) |
2023 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(2) |
Aug
|
Sep
(5) |
Oct
(3) |
Nov
|
Dec
|
From: Christoph K. <ku...@ku...> - 2023-10-17 06:35:04
|
Hi Haoxi, thanks for your remarks. I'm aware that the syntax of the command was wrong. That was not my problem. I just wanted to point out to the maintainers, that a program should not segfault, whatever the command line would be. This could be a security issue. -- Christoph > Am 16.10.2023 um 22:15 schrieb Haoxi Tan <hao...@gm...>: > > Hi Christoph, > > I don't think at the mome 3.7.3 will build for Mac, since it depends on a version of FUSE that Mac doesn't support. > > The only actively maintained sshfs for mac I can find is here > https://github.com/tormodwill/macSSHFS <https://github.com/tormodwill/macSSHFS>, maybe try to build that from source? > > Also, I don't think 2.10 being too old might be the problem here; the segmentation fault might be a different problem, such as the fact that no mountpoint was specified. > > try: > $ mkdir remote > $ sshfs foo@bar: remote/ > > > On Tue, 17 Oct 2023 at 01:35, Christoph Kukulies via fuse-sshfs <fus...@li... <mailto:fus...@li...>> wrote: > I was suffering from some problems with sshfs mounts under was told, my 2.10 was too old. > > $ sshfs foo@bar: > Segmentation fault: 11 > $ > > So I git cloned sshfs 3.7.3 and tried to build with the following result: > > > $ pwd > /Users/kuku/Downloads/sshfs-3.7.3/build > $ meson .. > The Meson build system > Version: 1.1.1 > Source dir: /Users/kuku/Downloads/sshfs-3.7.3 > Build dir: /Users/kuku/Downloads/sshfs-3.7.3/build > Build type: native build > Project name: sshfs > Project version: 3.7.3 > C compiler for the host machine: cc (clang 13.0.0 "Apple clang version 13.0.0 (clang-1300.0.29.3)") > C linker for the host machine: cc ld64 711 > Host machine cpu family: x86_64 > Host machine cpu: x86_64 > ../meson.build:5: WARNING: Consider using the built-in warning_level option instead of using "-Wall". > ../meson.build:5: WARNING: Consider using the built-in warning_level option instead of using "-Wextra". > Program rst2man.py found: YES (/Users/kuku/anaconda3/bin/rst2man.py) > Configuring config.h using configuration > Found pkg-config: /opt/local/bin/pkg-config (0.29.2) > Found CMake: /opt/local/bin/cmake (3.24.4) > Run-time dependency fuse3 found: NO (tried pkgconfig, framework and cmake) > > ../meson.build:47:15: ERROR: Dependency "fuse3" not found, tried pkgconfig, framework and cmake > > A full log can be found at /Users/kuku/Downloads/sshfs-3.7.3/build/meson-logs/meson-log.txt > WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated. > > Here I stand at the moment, not knowing how to preceed. > > -- > Christoph > > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... <mailto:fus...@li...> > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs <https://lists.sourceforge.net/lists/listinfo/fuse-sshfs> |
From: Haoxi T. <hao...@gm...> - 2023-10-16 20:15:51
|
Hi Christoph, I don't think at the mome 3.7.3 will build for Mac, since it depends on a version of FUSE that Mac doesn't support. The only actively maintained sshfs for mac I can find is here https://github.com/tormodwill/macSSHFS, maybe try to build that from source? Also, I don't think 2.10 being too old might be the problem here; the segmentation fault might be a different problem, such as the fact that no mountpoint was specified. try: $ mkdir remote $ sshfs foo@bar: remote/ On Tue, 17 Oct 2023 at 01:35, Christoph Kukulies via fuse-sshfs < fus...@li...> wrote: > I was suffering from some problems with sshfs mounts under was told, my > 2.10 was too old. > > $ sshfs foo@bar: > Segmentation fault: 11 > $ > > So I git cloned sshfs 3.7.3 and tried to build with the following result: > > > $ pwd > /Users/kuku/Downloads/sshfs-3.7.3/build > $ meson .. > The Meson build system > Version: 1.1.1 > Source dir: /Users/kuku/Downloads/sshfs-3.7.3 > Build dir: /Users/kuku/Downloads/sshfs-3.7.3/build > Build type: native build > Project name: sshfs > Project version: 3.7.3 > C compiler for the host machine: cc (clang 13.0.0 "Apple clang version > 13.0.0 (clang-1300.0.29.3)") > C linker for the host machine: cc ld64 711 > Host machine cpu family: x86_64 > Host machine cpu: x86_64 > ../meson.build:5: WARNING: Consider using the built-in warning_level > option instead of using "-Wall". > ../meson.build:5: WARNING: Consider using the built-in warning_level > option instead of using "-Wextra". > Program rst2man.py found: YES (/Users/kuku/anaconda3/bin/rst2man.py) > Configuring config.h using configuration > Found pkg-config: /opt/local/bin/pkg-config (0.29.2) > Found CMake: /opt/local/bin/cmake (3.24.4) > Run-time dependency fuse3 found: NO (tried pkgconfig, framework and cmake) > > ../meson.build:47:15: ERROR: Dependency "fuse3" not found, tried > pkgconfig, framework and cmake > > A full log can be found > at /Users/kuku/Downloads/sshfs-3.7.3/build/meson-logs/meson-log.txt > WARNING: Running the setup command as `meson [options]` instead of `meson > setup [options]` is ambiguous and deprecated. > > Here I stand at the moment, not knowing how to preceed. > > -- > Christoph > > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs > |
From: Christoph K. <ku...@ku...> - 2023-10-16 15:34:41
|
I was suffering from some problems with sshfs mounts under was told, my 2.10 was too old. $ sshfs foo@bar: Segmentation fault: 11 $ So I git cloned sshfs 3.7.3 and tried to build with the following result: $ pwd /Users/kuku/Downloads/sshfs-3.7.3/build $ meson .. The Meson build system Version: 1.1.1 Source dir: /Users/kuku/Downloads/sshfs-3.7.3 Build dir: /Users/kuku/Downloads/sshfs-3.7.3/build Build type: native build Project name: sshfs Project version: 3.7.3 C compiler for the host machine: cc (clang 13.0.0 "Apple clang version 13.0.0 (clang-1300.0.29.3)") C linker for the host machine: cc ld64 711 Host machine cpu family: x86_64 Host machine cpu: x86_64 ../meson.build:5: WARNING: Consider using the built-in warning_level option instead of using "-Wall". ../meson.build:5: WARNING: Consider using the built-in warning_level option instead of using "-Wextra". Program rst2man.py found: YES (/Users/kuku/anaconda3/bin/rst2man.py) Configuring config.h using configuration Found pkg-config: /opt/local/bin/pkg-config (0.29.2) Found CMake: /opt/local/bin/cmake (3.24.4) Run-time dependency fuse3 found: NO (tried pkgconfig, framework and cmake) ../meson.build:47:15: ERROR: Dependency "fuse3" not found, tried pkgconfig, framework and cmake A full log can be found at /Users/kuku/Downloads/sshfs-3.7.3/build/meson-logs/meson-log.txt WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated. Here I stand at the moment, not knowing how to preceed. -- Christoph |
From: Haoxi T. <hao...@gm...> - 2023-09-22 11:11:23
|
The reported bug by Eberhard has been fixed by reverting the PR that introduced very complex, potentially untested request size negotiation logic that may cause deadlocks. The fixed release is here https://github.com/deadbeefsociety/sshfs/releases/tag/sshfs-3.7.4a Thanks for the bug report! Please keep them coming. Warm regards, Haoxi On Thu, Sep 21, 2023 at 10:45 PM Eberhard Kuemmerle <e.k...@fz...> wrote: > > Hi, > > I have severe problems with sshfs-3.7.4, see my bug report here: https://bugzilla.suse.com/show_bug.cgi?id=1215574 > > Best regards, > Eberhard > > > Am 14.09.23 um 00:25 schrieb Haoxi Tan: > > Hi all, > > It's been a while.. So I thought, let's package up all the changes and > fixes made in the past year or so and put it in a release. > > https://github.com/deadbeefsociety/sshfs/releases/tag/sshfs-3.7.4 > > Changelog: > > - Support request size negotiation and increased throughput on > high-latency connections > - Supports connecting to vsock (7) via shfs -o vsock=CID:PORT > - README in markdown instead of rst > - Various test fixes > > This is the first release since the last maintainer, and not much has > changed. Now there's a rudimentary Github Actions CI/CD that builds > and runs the tests, which will make future PRs much easier. > > Please help test it if you'd like, report bugs, and if you're a distro > maintainer, put it into your bleeding edge and testing branches; after > a couple months to a year of stability, hopefully this would be ready > to be merged into stable distro releases. > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs |
From: Haoxi T. <hao...@gm...> - 2023-09-21 13:03:28
|
Hi Eberhard, First of all thanks for the bug report! You said in your bug report that > but when I try to login graphically, the login hangs because many processes hang with status "D": >The sshfs process does not die but file access to the sshfs filesystem is then no longer possible. Since SSHFS uses fuse, under potentially unstable network conditions (or just high load with a directory that has a LOT of files in it and recursive folders), it can in fact hang and cause file manager and other processes that use the GUI to hang. I have experienced similar situations before. Can you provide some brief info about: - what's your uname -a - was sshfs the only software you updated recently? - how many files do you have in the mounted directory? (output of find . | wc) If it's possible, I would also like some logs with sshfs running in debug mode (-d) and a coredump of sshfs while it is hanging as well. You can probably generate a core file by SSH'ing into the stuck machine / switching to a TTY and just gcore'ing the sshfs process. If you don't want to provide any of that it's fine, I can try to replicate the problem once you give me the exact OS and kernel version so I can replicate the bug. Warm regards, Haoxi On Thu, Sep 21, 2023 at 10:45 PM Eberhard Kuemmerle <e.k...@fz...> wrote: > > Hi, > > I have severe problems with sshfs-3.7.4, see my bug report here: https://bugzilla.suse.com/show_bug.cgi?id=1215574 > > Best regards, > Eberhard > > > Am 14.09.23 um 00:25 schrieb Haoxi Tan: > > Hi all, > > It's been a while.. So I thought, let's package up all the changes and > fixes made in the past year or so and put it in a release. > > https://github.com/deadbeefsociety/sshfs/releases/tag/sshfs-3.7.4 > > Changelog: > > - Support request size negotiation and increased throughput on > high-latency connections > - Supports connecting to vsock (7) via shfs -o vsock=CID:PORT > - README in markdown instead of rst > - Various test fixes > > This is the first release since the last maintainer, and not much has > changed. Now there's a rudimentary Github Actions CI/CD that builds > and runs the tests, which will make future PRs much easier. > > Please help test it if you'd like, report bugs, and if you're a distro > maintainer, put it into your bleeding edge and testing branches; after > a couple months to a year of stability, hopefully this would be ready > to be merged into stable distro releases. > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs |
From: Eberhard K. <e.k...@fz...> - 2023-09-21 12:45:24
|
Hi, I have severe problems with sshfs-3.7.4, see my bug report here: https://bugzilla.suse.com/show_bug.cgi?id=1215574 Best regards, Eberhard Am 14.09.23 um 00:25 schrieb Haoxi Tan: > Hi all, > > It's been a while.. So I thought, let's package up all the changes and > fixes made in the past year or so and put it in a release. > > https://github.com/deadbeefsociety/sshfs/releases/tag/sshfs-3.7.4 > > Changelog: > > - Support request size negotiation and increased throughput on > high-latency connections > - Supports connecting to vsock (7) via shfs -o vsock=CID:PORT > - README in markdown instead of rst > - Various test fixes > > This is the first release since the last maintainer, and not much has > changed. Now there's a rudimentary Github Actions CI/CD that builds > and runs the tests, which will make future PRs much easier. > > Please help test it if you'd like, report bugs, and if you're a distro > maintainer, put it into your bleeding edge and testing branches; after > a couple months to a year of stability, hopefully this would be ready > to be merged into stable distro releases. > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs |
From: <c....@po...> - 2023-09-15 07:25:57
|
Dear Haoxi Tan, thanks for this information and your work in that project. I'm member of maintenance team of "Back In Time" using sshfs. We will report back if somethings comes up. Kind Christian Buhtz https://github.com/bit-team/backintime |
From: Haoxi T. <hao...@gm...> - 2023-09-13 22:26:05
|
Hi all, It's been a while.. So I thought, let's package up all the changes and fixes made in the past year or so and put it in a release. https://github.com/deadbeefsociety/sshfs/releases/tag/sshfs-3.7.4 Changelog: - Support request size negotiation and increased throughput on high-latency connections - Supports connecting to vsock (7) via shfs -o vsock=CID:PORT - README in markdown instead of rst - Various test fixes This is the first release since the last maintainer, and not much has changed. Now there's a rudimentary Github Actions CI/CD that builds and runs the tests, which will make future PRs much easier. Please help test it if you'd like, report bugs, and if you're a distro maintainer, put it into your bleeding edge and testing branches; after a couple months to a year of stability, hopefully this would be ready to be merged into stable distro releases. |
From: ערן <exx...@gm...> - 2023-07-12 23:18:27
|
There was a typo in the original email. I meant tcsh, and not "tsch": https://en.wikipedia.org/wiki/Tcsh Thanks for your help! בתאריך יום ד׳, 12 ביולי 2023 ב-13:15 מאת ערן <exx...@gm...>: > Hi, > > I run SSHFS on a cluster which I am not root on. > Therefore, I use SSHFS 2.4 (as it does not require installing fuse which I > cannot as I'm not root, also I am able to run the executable out of the box > without apt install). > I am able to mount the following partition in tsch: > > echo "CENSORED" | ./sshfs/bin/sshfs -o password_stdin -o > StrictHostKeyChecking=no CENSORED@CENSORED.DOMAIN.COM:/ > /SOME/CENSORED/PATH > > But in bash something strange happens. > There is a blank line in the terminal. It waits a minute and then: > > Timeout waiting for prompt > > It seems to be unrelated to wait for fingerprint approval, as > StrictHostKeyChecking is applied. > This is strange as it happens in bash but not tsch. Maybe it is a > bash related issue? > > Distributor ID: Ubuntu > Description: Ubuntu 18.04.3 LTS > Release: 18.04 > Codename: bionic > > Thanks! > > |
From: ערן <exx...@gm...> - 2023-07-12 10:16:17
|
Hi, I run SSHFS on a cluster which I am not root on. Therefore, I use SSHFS 2.4 (as it does not require installing fuse which I cannot as I'm not root, also I am able to run the executable out of the box without apt install). I am able to mount the following partition in tsch: echo "CENSORED" | ./sshfs/bin/sshfs -o password_stdin -o StrictHostKeyChecking=no CENSORED@CENSORED.DOMAIN.COM:/ /SOME/CENSORED/PATH But in bash something strange happens. There is a blank line in the terminal. It waits a minute and then: Timeout waiting for prompt It seems to be unrelated to wait for fingerprint approval, as StrictHostKeyChecking is applied. This is strange as it happens in bash but not tsch. Maybe it is a bash related issue? Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic Thanks! |
From: <c....@po...> - 2023-06-30 07:21:06
|
Hello, when using sshfs (also ssh, sftp and other SSH based tools) some people do get an "Setting locales failed" error from the server and the connection is closed. I do understand why this happens and I also know how to "solve" or workaround it. The internet is full with "solutions". But what I would like to understand is why it is important to have the same locale on Server and Client? And if it is important (e.g. because of understanding file names) such an error should be treated serious and not worked around with all the "solutions" from the internet. Thanks in advance Christian Buhtz |
From: Greg T. <gd...@le...> - 2023-06-29 14:17:08
|
c....@po... writes: > So can you tell me something about the history of this > fuse-group-thing and how it is related to the present days? In addition to the other answer, the whole concept of "fuse" group is a local matter on some particular operating system, surely intended to gatekeep the use of mounting a fuse filesystem into the system namespace. It's not really about sshfs. My very hazy impression is that the trend is towards allowing user mounts, but with nodev,nosuid mount options (that's BSD speak). But if even one system will mount sshfs without being in fuse, the check is wrong, and you should just get rid of it, and focus on handling errors from sshfs instead -- and of course you need to do that anyway. |
From: Haoxi T. <hao...@gm...> - 2023-06-29 13:55:02
|
Hi Christian, I have checked on Fedora, Debian and Ubuntu, and based on my knowledge I can confirm that the fuse user groups are not needed in any of those distros. FUSE has been a kernel feature for a while. If you want to check that fuse is enabled in a system, you could check for the existance of /dev/fuse https://www.kernel.org/doc/html/latest/filesystems/fuse.html I would recommend removing that useless check and see if anything breaks. My best guess is nothing will. Best regards, Haoxi On Thu, Jun 29, 2023 at 11:41 PM <c....@po...> wrote: > > Hello together, > > based on (https://github.com/libfuse/sshfs) I'm aware that sshfs is > orphaned. But I hope that someone with knowledge about the internals and > the history of "sshfs" can validate an information/hypothesis for me. > > In short: Today does a user need to be member of the user group "fuse" > to use "sshfs" ? I do not understand the technical details or > implications of it, that is my problem. > > Background of this question: Looking around in the internet's forums, > (maybe outdated?) wikis and other support channels like stackoverflow I > often found the hint that a user should be part of the group "fuse". In > some cases this solved the problems. But most of this support threads > are years old. In more up-2-date locations like the Arch or Ubuntu Wiki > I can not find this information anymore. It seems to me that a user > don't need to be part of the "fuse" group anymore. > > More background: I'm an upstream maintainer of a backup software [1] > also using sshfs in the back. With some other folks I took over the > project last year. Because of some fuse-group-problems in the year 2013 > a fix was introduced. The application do check if the user is member of > "fuse" group if it exists and also do some error checking and messaging > around this topic. > My hypothesis is that this fuse-group-thing isn't needed anymore today > so the relevant code can be removed from the project [2]. > > So can you tell me something about the history of this fuse-group-thing > and how it is related to the present days? > > Thanks in advance > Christian Buhtz > Member of maintenance team "Back In Time" > > [1] -- <https://github.com/bit-team/backintime> > [2] -- > <https://github.com/bit-team/backintime/issues/1450#issuecomment-1597035415> > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs |
From: <c....@po...> - 2023-06-29 13:41:23
|
Hello together, based on (https://github.com/libfuse/sshfs) I'm aware that sshfs is orphaned. But I hope that someone with knowledge about the internals and the history of "sshfs" can validate an information/hypothesis for me. In short: Today does a user need to be member of the user group "fuse" to use "sshfs" ? I do not understand the technical details or implications of it, that is my problem. Background of this question: Looking around in the internet's forums, (maybe outdated?) wikis and other support channels like stackoverflow I often found the hint that a user should be part of the group "fuse". In some cases this solved the problems. But most of this support threads are years old. In more up-2-date locations like the Arch or Ubuntu Wiki I can not find this information anymore. It seems to me that a user don't need to be part of the "fuse" group anymore. More background: I'm an upstream maintainer of a backup software [1] also using sshfs in the back. With some other folks I took over the project last year. Because of some fuse-group-problems in the year 2013 a fix was introduced. The application do check if the user is member of "fuse" group if it exists and also do some error checking and messaging around this topic. My hypothesis is that this fuse-group-thing isn't needed anymore today so the relevant code can be removed from the project [2]. So can you tell me something about the history of this fuse-group-thing and how it is related to the present days? Thanks in advance Christian Buhtz Member of maintenance team "Back In Time" [1] -- <https://github.com/bit-team/backintime> [2] -- <https://github.com/bit-team/backintime/issues/1450#issuecomment-1597035415> |
From: Nikolaus R. <Nik...@ra...> - 2023-02-21 09:51:53
|
On Feb 21 2023, Johann Petrak <joh...@gm...> wrote: > I completely understand that volunteers and former contributors may not > have the time to look into this, but > I am a bit frustrated that such an important part of linux apparently does > not receive the attention and (financial, time) > support by (commercial) downstream Linux distributors. Welcome to the world of open source. > Just so I understand things correctly: is the archived sshfs repo the most > recent source code repository for the sshfs > everyone and their dog are using all over the glob? ( insert wide-eye-emoji > here). I don't think this is a question that anyone can answer authoritatively. My personal guess is that this is true. If you look at the archives for this list, I think there have been at least two annoucements of forking and/or resuming maintenance of SSHFS (one of them by porting to Rust). I am not sure if any of them ever got traction. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« |
From: Haoxi T. <hao...@gm...> - 2023-02-21 09:50:54
|
Hi Johann, >From useful forks (https://useful-forks.github.io/?repo=libfuse/sshfs) it looks like the most up to date (unofficial) repo is https://github.com/deadbeefsociety/sshfs - this one I am in charge of maintaining. It contains merged PRs that were not merged in the archived sshfs repo, as well as code from a couple of other forks. The second most recent is https://github.com/neunenak/sshfs which is as of last year being ported to Rust. It doesn't look like there were any activities on either since last year since life happens and what not. Most maintainers are still using the archived version. I didn't get a lot of pull requests on the deadbeefsociety fork, there's been one issue so far, if you can raise the issue you mentioned above to there that'd be great. Feel free to just copy some stuff from your emails above to put it in. Thanks, Haoxi On Tue, Feb 21, 2023 at 7:37 PM Johann Petrak <joh...@gm...> wrote: > > > > On Tue, 21 Feb 2023 at 10:15, Nikolaus Rath <nik...@ra...> wrote: >> >> On Tue, 21 Feb 2023, at 09:09, Nikolaus Rath wrote: >> >> On Tue, 21 Feb 2023, at 07:21, Johann Petrak wrote: >> >> BTW, could I ask if using that option works for anyone else? I have tried this on quite a number of different computers, >> with the same result everywhere: does not work. >> >> >> It looks like you also filed a bug, https://github.com/libfuse/libfuse/issues/738. Let's continue the discussion there, so that things are in one place. >> >> >> Nevermind my previous email, I just noticed that this was reported against libfuse rather than SSHFS. So this list is the best place for discussing it. >> > > Yes, sorry, I was reluctant to report in the sshfs repo since it is archived and I believe I read somewhere to report problems to libfuse. > > >> >> For what it's worth, I am seeing the same behavior: >> >> nikratio@vostro ~/tmp> sshfs -f ebox: mnt -o idmap=file,uidfile=uidfile.txt,gidfile=gidfile.txt >> nikratio@vostro ~/tmp [1]> >> > > Thanks for confirming this behavior! > > I completely understand that volunteers and former contributors may not have the time to look into this, but > I am a bit frustrated that such an important part of linux apparently does not receive the attention and (financial, time) > support by (commercial) downstream Linux distributors. > > Unfortunately I am not a C programmer and know almost nothing about the underlying libraries and methods, so > not sure if I could be of any help here. > > Just so I understand things correctly: is the archived sshfs repo the most recent source code repository for the sshfs > everyone and their dog are using all over the glob? ( insert wide-eye-emoji here). > > Cheers, > Johann > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs |
From: Johann P. <joh...@gm...> - 2023-02-21 09:37:15
|
On Tue, 21 Feb 2023 at 10:15, Nikolaus Rath <nik...@ra...> wrote: > On Tue, 21 Feb 2023, at 09:09, Nikolaus Rath wrote: > > On Tue, 21 Feb 2023, at 07:21, Johann Petrak wrote: > > BTW, could I ask if using that option works for anyone else? I have tried > this on quite a number of different computers, > with the same result everywhere: does not work. > > > It looks like you also filed a bug, > https://github.com/libfuse/libfuse/issues/738. Let's continue the > discussion there, so that things are in one place. > > > Nevermind my previous email, I just noticed that this was reported against > libfuse rather than SSHFS. So this list is the best place for discussing > it. > > Yes, sorry, I was reluctant to report in the sshfs repo since it is archived and I believe I read somewhere to report problems to libfuse. > For what it's worth, I am seeing the same behavior: > > nikratio@vostro ~/tmp> sshfs -f ebox: mnt -o > idmap=file,uidfile=uidfile.txt,gidfile=gidfile.txt > nikratio@vostro ~/tmp [1]> > > Thanks for confirming this behavior! I completely understand that volunteers and former contributors may not have the time to look into this, but I am a bit frustrated that such an important part of linux apparently does not receive the attention and (financial, time) support by (commercial) downstream Linux distributors. Unfortunately I am not a C programmer and know almost nothing about the underlying libraries and methods, so not sure if I could be of any help here. Just so I understand things correctly: is the archived sshfs repo the most recent source code repository for the sshfs everyone and their dog are using all over the glob? ( insert wide-eye-emoji here). Cheers, Johann |
From: Nikolaus R. <nik...@ra...> - 2023-02-21 09:29:32
|
Hi, Sorry, I should have been more precise. Here's what I get: nikratio@vostro ~/tmp> gdb ~/in-progress/sshfs/build/sshfs (gdb) b exit (gdb) run -f ebox: mnt -o idmap=file,uidfile=uidfile.txt,gidfile=gidfile.txt Starting program: /home/nikratio/in-progress/sshfs/build/sshfs -f ebox: mnt -o idmap=file,uidfile=uidfile.txt,gidfile=gidfile.txt [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Detaching after fork from child process 608681] [Detaching after fork from child process 608682] [Detaching after fork from child process 608691] Breakpoint 1, __GI_exit (status=status@entry=1) at exit.c:139 139 exit.c: No such file or directory. (gdb) bt #0 __GI_exit (status=status@entry=1) at exit.c:139 #1 0x0000555555559190 in main (argc=<optimized out>, argv=<optimized out>) at ../sshfs.c:4396 That is this part of the code: res = fuse_daemonize(sshfs.foreground); if (res == -1) { fuse_unmount(fuse); fuse_destroy(fuse); exit(1); } I've got no idea why passing idmap=file would affect the behavior of fuse_daemonize(), which is pretty-much a no-op anyway when -f is specified: https://libfuse.github.io/doxygen/helper_8c_source.html#l00254 Therefore, my best guess is that the actual problem is with option parsing. However, running under Valgrind does not show any errors. Trying to step through the call to fuse_daemonize(), I'm getting another problem: (gdb) b sshfs.c:4392 Breakpoint 1 at 0x4f41: file ../sshfs.c, line 4392. (gdb) run -f ebox: mnt -o idmap=file,uidfile=uidfile.txt,gidfile=gidfile.txt Starting program: /home/nikratio/in-progress/sshfs/build/sshfs -f ebox: mnt -o idmap=file,uidfile=uidfile.txt,gidfile=gidfile.txt [...] [Inferior 1 (process 614244) exited with code 01] So it seemingly never hits that line, even though it comes sequentially before the exit? Not sure what's going on here (and sadly lacking the time to look in more detail). Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« |
From: Nikolaus R. <nik...@ra...> - 2023-02-21 09:15:16
|
On Tue, 21 Feb 2023, at 09:09, Nikolaus Rath wrote: > On Tue, 21 Feb 2023, at 07:21, Johann Petrak wrote: >> BTW, could I ask if using that option works for anyone else? I have tried this on quite a number of different computers, >> with the same result everywhere: does not work. > > It looks like you also filed a bug, https://github.com/libfuse/libfuse/issues/738. Let's continue the discussion there, so that things are in one place. Nevermind my previous email, I just noticed that this was reported against libfuse rather than SSHFS. So this list is the best place for discussing it. For what it's worth, I am seeing the same behavior: nikratio@vostro ~/tmp> sshfs -f ebox: mnt -o idmap=file,uidfile=uidfile.txt,gidfile=gidfile.txt nikratio@vostro ~/tmp [1]> -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« |
From: Nikolaus R. <nik...@ra...> - 2023-02-21 09:10:20
|
On Tue, 21 Feb 2023, at 07:21, Johann Petrak wrote: > BTW, could I ask if using that option works for anyone else? I have tried this on quite a number of different computers, > with the same result everywhere: does not work. It looks like you also filed a bug, https://github.com/libfuse/libfuse/issues/738. Let's continue the discussion there, so that things are in one place. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« |
From: Johann P. <joh...@gm...> - 2023-02-21 07:22:17
|
BTW, could I ask if using that option works for anyone else? I have tried this on quite a number of different computers, with the same result everywhere: does not work. Easiest way to reproduce: * make sure sshd is installed and running * create two subdirectories somewhere, e.g. "server", "client" * create the two files: uidfile, gidfile * files can be left empty or get filled e.g. with yourusername:youruserid, yourgroupname:yourgroupid * try mounting the server directory at the client mountpoint: sshfs -d localhost:/PATHTHO/server /PATHTO/client -o idmap=file,uidfile=uidfile,gidfile=gidfile * (the -d options prevents the command from spawning the mount process in the background and should normally stay active until terminated, but because of the bug, the command exits and does not mount anything) I would be very interested if this works for anyone? Cheers, Johann On Mon, 20 Feb 2023 at 20:41, Nikolaus Rath <nik...@ra...> wrote: > > > On Mon, 20 Feb 2023, at 13:07, Johann Petrak wrote: > > I am pretty puzzled and desparate because of this: I wanted to try and use > the option idmap=file like so: > > sshfs HOST:DIR MOUNTPOINT -i idmap=file,uidfile=uidfile,gidfile=gidfile > > When I run in debug mode, this is the output I get: > > user1: remote uid 1000 => local uid 1000 > user2: remote uid 1003 => local uid 1002 > group1: remote gid 1000 => local gid 1000 > group2: remote gid 10000 => local gid 10000 > SSHFS version 3.7.1 > executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <SERVERADDRESS> > <-s> <sftp> > Enter passphrase for key 'HOME/.ssh/id_rsa': > Server version: 3 > Extension: pos...@op... <1> > Extension: st...@op... <2> > Extension: fst...@op... <2> > Extension: har...@op... <1> > Extension: fs...@op... <1> > Extension: lse...@op... <1> > Extension: li...@op... <1> > Extension: exp...@op... <1> > > After which it exits with exit code 1 > > > Could you try running under gdb, and run "stacktrace" after it exits? > > Best, > -Nikolaus > > > -- > GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > > > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs > |
From: Johann P. <joh...@gm...> - 2023-02-20 19:53:54
|
Thanks Nikolaus for the suggestion. I am unfamiliar with gdb so I might need instructions for how to do this right. What I tried is this: gdb --args sshfs -d localhost:/home/johann/tmp/server /home/johann/tmp/client -o idmap=file,uidfile=uidfile,gidfile=gidfile then entered "run" in the gdb prompt. Output: Starting program: /usr/bin/sshfs -d localhost:/home/johann/tmp/server /home/johann/tmp/client -o idmap=file,uidfile=uidfile,gidfile=gidfile [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". SSHFS version 3.7.1 [Detaching after fork from child process 223813] [Detaching after fork from child process 223815] executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <localhost> <-s> <sftp> johann@localhost's password: Server version: 3 Extension: pos...@op... <1> Extension: st...@op... <2> Extension: fst...@op... <2> Extension: har...@op... <1> Extension: fs...@op... <1> Extension: lse...@op... <1> Extension: li...@op... <1> Extension: exp...@op... <1> [Detaching after fork from child process 223882] [Inferior 1 (process 223810) exited with code 01] (gdb) I then entered "stacktrace" for which i got the response: Undefined command: "stacktrace". Try "help". I also tried "bt" and got the response "no stack". Cheers, Johann On Mon, 20 Feb 2023 at 20:41, Nikolaus Rath <nik...@ra...> wrote: > > > On Mon, 20 Feb 2023, at 13:07, Johann Petrak wrote: > > I am pretty puzzled and desparate because of this: I wanted to try and use > the option idmap=file like so: > > sshfs HOST:DIR MOUNTPOINT -i idmap=file,uidfile=uidfile,gidfile=gidfile > > When I run in debug mode, this is the output I get: > > user1: remote uid 1000 => local uid 1000 > user2: remote uid 1003 => local uid 1002 > group1: remote gid 1000 => local gid 1000 > group2: remote gid 10000 => local gid 10000 > SSHFS version 3.7.1 > executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <SERVERADDRESS> > <-s> <sftp> > Enter passphrase for key 'HOME/.ssh/id_rsa': > Server version: 3 > Extension: pos...@op... <1> > Extension: st...@op... <2> > Extension: fst...@op... <2> > Extension: har...@op... <1> > Extension: fs...@op... <1> > Extension: lse...@op... <1> > Extension: li...@op... <1> > Extension: exp...@op... <1> > > After which it exits with exit code 1 > > > Could you try running under gdb, and run "stacktrace" after it exits? > > Best, > -Nikolaus > > > -- > GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > > > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs > |
From: Nikolaus R. <nik...@ra...> - 2023-02-20 19:41:40
|
On Mon, 20 Feb 2023, at 13:07, Johann Petrak wrote: > I am pretty puzzled and desparate because of this: I wanted to try and use the option idmap=file like so: > > `sshfs HOST:DIR MOUNTPOINT -i idmap=file,uidfile=uidfile,gidfile=gidfile` > > When I run in debug mode, this is the output I get: > > user1: remote uid 1000 => local uid 1000 > user2: remote uid 1003 => local uid 1002 > group1: remote gid 1000 => local gid 1000 > group2: remote gid 10000 => local gid 10000 > SSHFS version 3.7.1 > executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <SERVERADDRESS> <-s> <sftp> > Enter passphrase for key 'HOME/.ssh/id_rsa': > Server version: 3 > Extension: pos...@op... <1> > Extension: st...@op... <2> > Extension: fst...@op... <2> > Extension: har...@op... <1> > Extension: fs...@op... <1> > Extension: lse...@op... <1> > Extension: li...@op... <1> > Extension: exp...@op... <1> > > After which it exits with exit code 1 Could you try running under gdb, and run "stacktrace" after it exits? Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« |
From: Johann P. <joh...@gm...> - 2023-02-20 13:08:39
|
I am pretty puzzled and desparate because of this: I wanted to try and use the option idmap=file like so: sshfs HOST:DIR MOUNTPOINT -i idmap=file,uidfile=uidfile,gidfile=gidfile Where the uidfile and gidfile contain lines of the format "localname:remoteid" But running this command does not perform any mounting at all! When I run the sshfs command with thee "-d" option, it exits with exit code 1 but without showing any error message at all. Running instead with idmap=user like so sshfs HOST:DIR MOUNTPOINT -i idmap=user works fine, except of course, that ids do not get mapped properly. I could not find any mention of this anywhere, and almost no mention of usage of the idmap=file option. Is there anything known about this? Does this work for others? When I run in debug mode, this is the output I get: user1: remote uid 1000 => local uid 1000 user2: remote uid 1003 => local uid 1002 group1: remote gid 1000 => local gid 1000 group2: remote gid 10000 => local gid 10000 SSHFS version 3.7.1 executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <SERVERADDRESS> <-s> <sftp> Enter passphrase for key 'HOME/.ssh/id_rsa': Server version: 3 Extension: pos...@op... <1> Extension: st...@op... <2> Extension: fst...@op... <2> Extension: har...@op... <1> Extension: fs...@op... <1> Extension: lse...@op... <1> Extension: li...@op... <1> Extension: exp...@op... <1> After which it exits with exit code 1 |
From: Greg S. <gre...@pr...> - 2022-12-11 07:57:14
|
Thanks for taking up maintenance of the existing C codebase, Hash (and I'm pleased to see that some of the minor improvements around the tests and tooling that I made have been incorporated into your fork :) ). I still think that it would be good to have a Rust version of sshfs. Unfortunately, the strategy that I had in mind for doing so (namely, auto-converting the C codebase and then manually making the resulting Rust code idiomatic and safe) has proven to be a sizeable challenge - the resulting autoconverted code is quite messy, and it's proven difficult to make gradual improvements to it. I'm now thinking that the best way to have a sshfs-like tool in Rust would be to write one in Rust from scratch, and that would almost certainly result in a program that has at least subtly different behavior from the existing sshfs. In any case, until such a program exists and is as good or better than current sshfs, it's good to have the existing codebase being maintained - I'd certainly like sshfs to continue being available in my distro's package manager! I'll see if there are any useful C or Python test-related PRs I might be able to make to your fork. -Greg Sent with Proton Mail secure email. ------- Original Message ------- On Saturday, December 10th, 2022 at 11:32 PM, Haoxi Tan <hao...@gm...> wrote: > Hi all, > > Me and my friend were very sad when we saw the deprecation of the > sshfs project. Me and many of my peers have used sshfs for a variety > of things as sysadmins, pentesters and during student years, and > decided to do some light maintenance work for it to keep the ship > afloat for as long as we can. > > The repo is at https://github.com/deadbeefsociety/sshfs, and as of the > time of writing it is the most updated and recent branch (32 commits > ahead of libfuse/sshfs) as shown by > https://useful-forks.github.io/?repo=libfuse/sshfs. We have no plans > of porting it to Rust (but we cheer on our friend Greg/neunenak and > wish him the best of luck). > > Instead we will be focusing on testing and merging PRs from the old > repo (for which we have merged #267, #277, with plans for #260 to be > merged), we've converted the README to markdown (basically most of > what #238 is), and fixing up bugs in the old issue tracker starting > with the most critical ones. In attempts to learn the code, we also > plan to make an extensive code documentation project branch where the > code will be almost line-by-line commented, probably over a couple > weekend benders. > > Security is crucial and we understand that C code tends to have a lot > of memory corruption vulnerabilities, which are especially tricky to > find and fix when the program is multithreaded (like this one). That's > why we've enabled the new private security vulnerability reporting > program on Github and you can report your findings here > https://github.com/deadbeefsociety/sshfs/security/advisories. Please > make sure you have a valid proof of concept and clear explanation > attached, and if you know your C, make a PR to fix it. > > Please submit your bug reports and PRs to our fork if you wish, we > have no plans of taking over the whole thing before the six months of > active dev is up, as everybody's mileage varies. We will try to stay > on top of things, and merge PRs relatively quickly as long as they > pass tests and normal usage. > > Best regards, > Hash > > > _______________________________________________ > fuse-sshfs mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-sshfs |