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
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Dr. T. O. <tho...@un...> - 2024-05-11 16:27:31
|
Hi, I'm running an sshfs client on a VM that gets a number of directories from a server. The client and the server are permanently online in a datacenter context. They have rather stable connection, but there's some firewalling between them that I _suspect_ interferes with sshfs. After some time, in the scale of days, the sshfs connections freeze. The mounts get stuck, the ssh/sftp processes behind sshfs just hang there. Any process accessing the mounts gets stuck in uninterruptible sleep. I once had a workaround in place that rebooted the server each night. That reduced the pain, but is undesirable for other reasons (killing cron jobs, for example). I suppose this is some bad interaction with either the virtual machine networking or the firewalling between the client and the server, or a combination of all. At any rate: ServerAliveInterval=15 should cover this, no? I do not see reconnects fixing the mounts. I don't see I/O errors, ever … I just have processes being stuck in unterruptible sleep. For reasons, I got a somewhat complex setup with a main mount # fstab us...@fs...mewhere.local: /mnt/writable fuse.sshfs _netdev,delay_connect,port=26,identityfile=/home/user/.ssh/id_rsa,reconnect,ServerAliveInterval=15,ServerAliveCountMax=2,allow_other 0 0 and sub-directories of this being bind-mounted to other locations (mounting the sub-directories directly failed right away for some reason, I noted that back then and just went with the bind mounts). /mnt/writable/foo/bar /mnt/other/foo/bar none bind 0 0 /mnt/writable/foo/baz /mnt/other/foo/baz none bind 0 0 Anything trying to access the mount points gets stuck. There is a webserver trying to serve from the sshfs mounts that I naturally cannot stop. An I/O error would be a big improvement! root@client:~# cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04.4 LTS" root@client:~# sshfs --version SSHFS version 3.7.1 FUSE library version 3.10.5 using FUSE kernel interface version 7.31 fusermount3 version: 3.10.5 I cannot detail the network setup, except that it _should_ be physically stable, with redundant links and all. I just take a guess at firewalling doing weird stuff. At any rate: sshfs should at some point diagnose a broken connection, but doesn't. The ssh connections just seem to hang around, doing nothing. I did `kill -9` on all ssh/sftp processes and eventually they seem to be re-started, but that does not seem to affect frozen processes at all. I am not sure, but this does seem to make mounts available to new processes, but does not affect the frozen ones at all. For clarity, the man page states: If it is acceptable to discard data being read or written, a quick workaround is to kill the responsible sshfs process, which will make any blocking operations on the mounted filesystem error out and thereby "unfreeze" the relevant applications. Note that force unmounting with fusermount -zu, on the other hand, does not help in this case and will leave read/write operations in the blocking state. Is this relating to the mount.fuse.sshfs process or to the ssh started for the actual connection? Also, for multiple mounts it's not that easy to figure out which ssh/sftp process is the right one (ppid 1 on all of them?). What finally worked now is `umount -f` on the mount points (after some time messing around). I might try a more structured approach with this next time. What is clear, after some years of experience with this now, is that any auto-healing of the sshfs mount, even with I/O errors, is just not happening. Also: Isn't it possible to make the processes killable? `kill -9` is supposed to work on stuck client processes on NFS. Why not with SSHFS? A FUSE limitation, I presume … Anyway, I'm thankful for any hints. Mainly, I wanted to have this documented at least. SSHFS is, sadly, no option for permanent mounts. It has an appeal because it offers Unix semantics, secure transport, and passwordless authentication without further infrastructure, but it does not like our network setup. I guess a properly broken network connection would be easier, not whatever happens here with the firewalling. Alrighty then, Thomas PS: I am moving away from this setup, also for hardware reasons, but wanted to finally give note about this particularily seriously non-workable sshfs setup. Any hints might be useful should I try some semi-permanent sshfs again. But so far, the experience gives me caution to try. -- Dr. Thomas Orgis HPC @ Universität Hamburg |
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 |