starred/s3fs-fuse
1
0
Fork 0
mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 13:26:00 +03:00
Code Issues 305 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #506] Repeatedly dropping mount: Transport endpoint is not connected. #281

New issue
Closed
opened 2026-03-04 01:44:00 +03:00 by kerem · 15 comments
kerem commented 2026-03-04 01:44:00 +03:00
Owner
Copy link

Originally created by @ruffle-b on GitHub (Nov 21, 2016).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/506

I have four s3 buckets mounted and one keeps on getting 'stuck'. ls shows the mountpoint thusly:

d????????? ? ? ? ? ? scripts

and any attempt to access it returns a "Transport endpoint is not connected" error. AFAICS it's only one bucket that's doing this but there is regular access to the content of that bucket so it could be use related. I can still access the content of my other s3fs mounted buckets.

Running with debug in the foreground I get:

# s3fs -d -d -f -o f2 -o curldbg -o end
point=eu-west-1,umask=0,iam_role=Rsync_Handler,uid=`id -u www-data`,gid=`id -g w
ww-data`,noatime,allow_other lls.scripts /mnt/scripts/ > s3fs.log.4 
*** Error in `s3fs': double free or corruption (fasttop): 0x00007f46f8000e60 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f4708b077e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x7fe0a)[0x7f4708b0fe0a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f4708b1398c]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNSs6assignERKSs+0xc0)[0x7f470935c460]
s3fs[0x45d246]
s3fs[0x411a4c]
/lib/x86_64-linux-gnu/libfuse.so.2(+0xdd97)[0x7f470a088d97]
/lib/x86_64-linux-gnu/libfuse.so.2(+0xe020)[0x7f470a089020]
/lib/x86_64-linux-gnu/libfuse.so.2(+0x147c6)[0x7f470a08f7c6]
/lib/x86_64-linux-gnu/libfuse.so.2(+0x15679)[0x7f470a090679]
/lib/x86_64-linux-gnu/libfuse.so.2(+0x11e38)[0x7f470a08ce38]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x770a)[0x7f4708e6070a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f4708b9682d]
======= Memory map: ========

The last few lines of the output log are:

[DBG] s3fs.cpp:get_object_attribute(406): [path=/]
[DBG] s3fs.cpp:check_object_access(560): [path=/lls_aws_scripts/show_instances]
[DBG] s3fs.cpp:get_object_attribute(406): [path=/lls_aws_scripts/show_instances]
[DBG] cache.cpp:GetStat(269): stat cache hit [path=/lls_aws_scripts/show_instances][time=101487.413873295][hit count=6]
[DBG] fdcache.cpp:ExistOpen(2010): [path=/lls_aws_scripts/show_instances][fd=7][ignore_existfd=false]
[DBG] fdcache.cpp:Open(1959): [path=/lls_aws_scripts/show_instances][size=-1][time=-1]
[DBG] fdcache.cpp:Dup(729): [path=/lls_aws_scripts/show_instances][fd=7][refcnt=2]
[INF]       fdcache.cpp:RowFlush(1418): [tpath=][path=/lls_aws_scripts/show_instances][fd=7]
[DBG] fdcache.cpp:Close(2051): [ent->file=/lls_aws_scripts/show_instances][ent->fd=7]
[DBG] fdcache.cpp:Close(696): [path=/lls_aws_scripts/show_instances][fd=7][refcnt=1]
[INF] s3fs.cpp:s3fs_flush(2166): [path=/lls_aws_scripts/show_instances][fd=7]
[DBG] s3fs.cpp:check_parent_object_access(666): [path=/lls_aws_scripts/show_instances]
[DBG] s3fs.cpp:check_object_access(560): [path=/lls_aws_scripts]
[DBG] s3fs.cpp:get_object_attribute(406): [path=/lls_aws_scripts]
[DBG] cache.cpp:GetStat(269): stat cache hit [path=/lls_aws_scripts/][time=101487.413873295][hit count=553]
[INF] s3fs.cpp:s3fs_flush(2166): [path=/lls_aws_scripts/show_instances][fd=7]
[DBG] s3fs.cpp:check_parent_object_access(666): [path=/lls_aws_scripts/show_instances]
[DBG] s3fs.cpp:check_object_access(560): [path=/]
[DBG] s3fs.cpp:get_object_attribute(406): [path=/]
[DBG] s3fs.cpp:check_object_access(560): [path=/lls_aws_scripts/show_instances]
[DBG] s3fs.cpp:check_object_access(560): [path=/lls_aws_scripts]
[DBG] s3fs.cpp:get_object_attribute(406): [path=/lls_aws_scripts]
[DBG] cache.cpp:GetStat(269): stat cache hit [path=/lls_aws_scripts/][time=101487.837869142][hit count=554]
[DBG] s3fs.cpp:get_object_attribute(406): [path=/lls_aws_scripts/show_instances]
[DBG] s3fs.cpp:check_object_access(560): [path=/]
[DBG] s3fs.cpp:get_object_attribute(406): [path=/]
[DBG] s3fs.cpp:check_object_access(560): [path=/lls_aws_scripts/show_instances]
[DBG] cache.cpp:GetStat(269): stat cache hit [path=/lls_aws_scripts/show_instances][time=101487.413873295][hit count=7]
[DBG] fdcache.cpp:ExistOpen(2010): [path=/lls_aws_scripts/show_instances][fd=7][ignore_existfd=false]
[DBG] fdcache.cpp:Open(1959): [path=/lls_aws_scripts/show_instances][size=-1][time=-1]
[DBG] s3fs.cpp:get_object_attribute(406): [path=/lls_aws_scripts/show_instances]
[DBG] cache.cpp:GetStat(269): stat cache hit [path=/lls_aws_scripts/show_instances][time=101487.837869142][hit count=8]
[DBG] fdcache.cpp:Dup(729): [path=/lls_aws_scripts/show_instances][fd=7][refcnt=2]
[DBG] fdcache.cpp:ExistOpen(2010): [path=/lls_aws_scripts/show_instances][fd=7][ignore_existfd=false]
[DBG] fdcache.cpp:Open(1959): [path=/lls_aws_scripts/show_instances][size=-1][time=-1]
[DBG] fdcache.cpp:Dup(729): [path=/lls_aws_scripts/show_instances][fd=7][refcnt=3]
[INF]       fdcache.cpp:RowFlush(1418): [tpath=][path=/lls_aws_scripts/show_instances][fd=7]
[DBG] fdcache.cpp:Close(2051): [ent->file=/lls_aws_scripts/show_instances][ent->fd=7]
[DBG] fdcache.cpp:Close(696): [path=/lls_aws_scripts/show_instances][fd=7][refcnt=2]

This happened four times yesterday. Unmounting and remounting makes it work for a while.

s3fs version 1.80, Ubuntu 16.04.1 LTS

I'm very happy to test, capture debug etc.

Originally created by @ruffle-b on GitHub (Nov 21, 2016). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/506 I have four s3 buckets mounted and one keeps on getting 'stuck'. ls shows the mountpoint thusly: > d????????? ? ? ? ? ? scripts and any attempt to access it returns a "Transport endpoint is not connected" error. AFAICS it's only one bucket that's doing this but there is regular access to the content of that bucket so it could be use related. I can still access the content of my other s3fs mounted buckets. Running with debug in the foreground I get: ``` # s3fs -d -d -f -o f2 -o curldbg -o end point=eu-west-1,umask=0,iam_role=Rsync_Handler,uid=`id -u www-data`,gid=`id -g w ww-data`,noatime,allow_other lls.scripts /mnt/scripts/ > s3fs.log.4 *** Error in `s3fs': double free or corruption (fasttop): 0x00007f46f8000e60 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f4708b077e5] /lib/x86_64-linux-gnu/libc.so.6(+0x7fe0a)[0x7f4708b0fe0a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f4708b1398c] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZNSs6assignERKSs+0xc0)[0x7f470935c460] s3fs[0x45d246] s3fs[0x411a4c] /lib/x86_64-linux-gnu/libfuse.so.2(+0xdd97)[0x7f470a088d97] /lib/x86_64-linux-gnu/libfuse.so.2(+0xe020)[0x7f470a089020] /lib/x86_64-linux-gnu/libfuse.so.2(+0x147c6)[0x7f470a08f7c6] /lib/x86_64-linux-gnu/libfuse.so.2(+0x15679)[0x7f470a090679] /lib/x86_64-linux-gnu/libfuse.so.2(+0x11e38)[0x7f470a08ce38] /lib/x86_64-linux-gnu/libpthread.so.0(+0x770a)[0x7f4708e6070a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f4708b9682d] ======= Memory map: ======== ``` The last few lines of the output log are: ``` [DBG] s3fs.cpp:get_object_attribute(406): [path=/] [DBG] s3fs.cpp:check_object_access(560): [path=/lls_aws_scripts/show_instances] [DBG] s3fs.cpp:get_object_attribute(406): [path=/lls_aws_scripts/show_instances] [DBG] cache.cpp:GetStat(269): stat cache hit [path=/lls_aws_scripts/show_instances][time=101487.413873295][hit count=6] [DBG] fdcache.cpp:ExistOpen(2010): [path=/lls_aws_scripts/show_instances][fd=7][ignore_existfd=false] [DBG] fdcache.cpp:Open(1959): [path=/lls_aws_scripts/show_instances][size=-1][time=-1] [DBG] fdcache.cpp:Dup(729): [path=/lls_aws_scripts/show_instances][fd=7][refcnt=2] [INF] fdcache.cpp:RowFlush(1418): [tpath=][path=/lls_aws_scripts/show_instances][fd=7] [DBG] fdcache.cpp:Close(2051): [ent->file=/lls_aws_scripts/show_instances][ent->fd=7] [DBG] fdcache.cpp:Close(696): [path=/lls_aws_scripts/show_instances][fd=7][refcnt=1] [INF] s3fs.cpp:s3fs_flush(2166): [path=/lls_aws_scripts/show_instances][fd=7] [DBG] s3fs.cpp:check_parent_object_access(666): [path=/lls_aws_scripts/show_instances] [DBG] s3fs.cpp:check_object_access(560): [path=/lls_aws_scripts] [DBG] s3fs.cpp:get_object_attribute(406): [path=/lls_aws_scripts] [DBG] cache.cpp:GetStat(269): stat cache hit [path=/lls_aws_scripts/][time=101487.413873295][hit count=553] [INF] s3fs.cpp:s3fs_flush(2166): [path=/lls_aws_scripts/show_instances][fd=7] [DBG] s3fs.cpp:check_parent_object_access(666): [path=/lls_aws_scripts/show_instances] [DBG] s3fs.cpp:check_object_access(560): [path=/] [DBG] s3fs.cpp:get_object_attribute(406): [path=/] [DBG] s3fs.cpp:check_object_access(560): [path=/lls_aws_scripts/show_instances] [DBG] s3fs.cpp:check_object_access(560): [path=/lls_aws_scripts] [DBG] s3fs.cpp:get_object_attribute(406): [path=/lls_aws_scripts] [DBG] cache.cpp:GetStat(269): stat cache hit [path=/lls_aws_scripts/][time=101487.837869142][hit count=554] [DBG] s3fs.cpp:get_object_attribute(406): [path=/lls_aws_scripts/show_instances] [DBG] s3fs.cpp:check_object_access(560): [path=/] [DBG] s3fs.cpp:get_object_attribute(406): [path=/] [DBG] s3fs.cpp:check_object_access(560): [path=/lls_aws_scripts/show_instances] [DBG] cache.cpp:GetStat(269): stat cache hit [path=/lls_aws_scripts/show_instances][time=101487.413873295][hit count=7] [DBG] fdcache.cpp:ExistOpen(2010): [path=/lls_aws_scripts/show_instances][fd=7][ignore_existfd=false] [DBG] fdcache.cpp:Open(1959): [path=/lls_aws_scripts/show_instances][size=-1][time=-1] [DBG] s3fs.cpp:get_object_attribute(406): [path=/lls_aws_scripts/show_instances] [DBG] cache.cpp:GetStat(269): stat cache hit [path=/lls_aws_scripts/show_instances][time=101487.837869142][hit count=8] [DBG] fdcache.cpp:Dup(729): [path=/lls_aws_scripts/show_instances][fd=7][refcnt=2] [DBG] fdcache.cpp:ExistOpen(2010): [path=/lls_aws_scripts/show_instances][fd=7][ignore_existfd=false] [DBG] fdcache.cpp:Open(1959): [path=/lls_aws_scripts/show_instances][size=-1][time=-1] [DBG] fdcache.cpp:Dup(729): [path=/lls_aws_scripts/show_instances][fd=7][refcnt=3] [INF] fdcache.cpp:RowFlush(1418): [tpath=][path=/lls_aws_scripts/show_instances][fd=7] [DBG] fdcache.cpp:Close(2051): [ent->file=/lls_aws_scripts/show_instances][ent->fd=7] [DBG] fdcache.cpp:Close(696): [path=/lls_aws_scripts/show_instances][fd=7][refcnt=2] ``` This happened four times yesterday. Unmounting and remounting makes it work for a while. s3fs version 1.80, Ubuntu 16.04.1 LTS I'm very happy to test, capture debug etc.
kerem closed this issue 2026-03-04 01:44:00 +03:00
kerem commented 2026-03-04 01:44:01 +03:00
Author
Owner
Copy link

@substa commented on GitHub (Dec 15, 2016):

Same problem here.
Temporarily I'm solving with a script to check if mountdir is writable, and eventually remount it.
I'm also logging the failures, and in the last 3 days this error occured 6 times (absolutely random).

<!-- gh-comment-id:267390614 --> @substa commented on GitHub (Dec 15, 2016): Same problem here. Temporarily I'm solving with a script to check if mountdir is writable, and eventually remount it. I'm also logging the failures, and in the last 3 days this error occured 6 times (absolutely random).
kerem commented 2026-03-04 01:44:01 +03:00
Author
Owner
Copy link

@rkroboth commented on GitHub (Jan 3, 2017):

I did some testing on how long it takes to write 300 10kb files:

  • to local file system: fraction of a second
  • to a good NFS over a very fast network: about a second
  • over S3FS from an EC2 m4 xlarge instance: about 75 seconds

It makes some sense to me, as under the hood S3FS is just hitting the S3 http api, so it should be much slower. I am just wondering if this slowness opens up opportunities for file system resources to max out, like file handles, connections, and so on, causing these hangs some people see?

<!-- gh-comment-id:270163662 --> @rkroboth commented on GitHub (Jan 3, 2017): I did some testing on how long it takes to write 300 10kb files: - to local file system: fraction of a second - to a good NFS over a very fast network: about a second - over S3FS from an EC2 m4 xlarge instance: about 75 seconds It makes some sense to me, as under the hood S3FS is just hitting the S3 http api, so it should be much slower. I am just wondering if this slowness opens up opportunities for file system resources to max out, like file handles, connections, and so on, causing these hangs some people see?
kerem commented 2026-03-04 01:44:01 +03:00
Author
Owner
Copy link

@rkroboth commented on GitHub (Jan 4, 2017):

Actually did some further testing, just doing a bunch of "reads" from a single bucket with about 1000 10kb files, via a single S3FS mount point. The reads were done using a php script, which forks off 15 children, then proceeds to randomly read files in a bucket. I did this on a m4 xlarge Amazon linux instance, and achieved a rate of about 300 files read per second. However invariably, after between 1 to 10 minutes, the mount point suddenly goes away and I get the error you mention "Transport endpoint is not connected." So definitely seems to be an issue here with the mount point intermittently disappearing.

<!-- gh-comment-id:270410698 --> @rkroboth commented on GitHub (Jan 4, 2017): Actually did some further testing, just doing a bunch of "reads" from a single bucket with about 1000 10kb files, via a single S3FS mount point. The reads were done using a php script, which forks off 15 children, then proceeds to randomly read files in a bucket. I did this on a m4 xlarge Amazon linux instance, and achieved a rate of about 300 files read per second. However invariably, after between 1 to 10 minutes, the mount point suddenly goes away and I get the error you mention "Transport endpoint is not connected." So definitely seems to be an issue here with the mount point intermittently disappearing.
kerem commented 2026-03-04 01:44:01 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Jan 5, 2017):

@rkroboth Could you re-run your test with the logging flags -d -d -f -o f2 -o curldbg and see if you can reproduce your symptoms? This will help us diagnose the issue.

<!-- gh-comment-id:270577325 --> @gaul commented on GitHub (Jan 5, 2017): @rkroboth Could you re-run your test with the logging flags `-d -d -f -o f2 -o curldbg` and see if you can reproduce your symptoms? This will help us diagnose the issue.
kerem commented 2026-03-04 01:44:01 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Jan 15, 2017):

@andrewgaul Thanks for your help.

@rkroboth @substa @ruffle-b I'm sorry for my late reply.
If you can, please try to run s3fs with readwrite_timeout(and connect_timeout) option.
If this problem depends on timeout, the result will change with these options.
And please try to use latest codes in master branch which is fixed a bug about multi-processes.

Thanks in advance for your assistance.

<!-- gh-comment-id:272683277 --> @ggtakec commented on GitHub (Jan 15, 2017): @andrewgaul Thanks for your help. @rkroboth @substa @ruffle-b I'm sorry for my late reply. If you can, please try to run s3fs with readwrite_timeout(and connect_timeout) option. If this problem depends on timeout, the result will change with these options. And please try to use latest codes in master branch which is fixed a bug about multi-processes. Thanks in advance for your assistance.
kerem commented 2026-03-04 01:44:02 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Jan 15, 2017):

#152 is the same issue

<!-- gh-comment-id:272684423 --> @ggtakec commented on GitHub (Jan 15, 2017): #152 is the same issue
kerem commented 2026-03-04 01:44:02 +03:00
Author
Owner
Copy link

@gkrinc commented on GitHub (May 23, 2017):

This started happening recently for us as well. We have an ansible task to get and make s3fs-fuse. Based on our deployment history I think this may be related to v1.81/1.82. The problem started happening this weekend shortly after provisioning new servers and therefore a new version of s3fs-fuse. Before that we would have been running v1.80.

Others have been experiencing this issues long before v1.81/1.82 though...

We haven't made any changes in our AWS environment related to permissions, bucket policies, etc.

I think we're going to try rolling back to v1.80 to see if it corrects the problem.

<!-- gh-comment-id:303405060 --> @gkrinc commented on GitHub (May 23, 2017): This started happening recently for us as well. We have an ansible task to get and make s3fs-fuse. Based on our deployment history I think this may be related to v1.81/1.82. The problem started happening this weekend shortly after provisioning new servers and therefore a new version of s3fs-fuse. Before that we would have been running v1.80. Others have been experiencing this issues long before v1.81/1.82 though... We haven't made any changes in our AWS environment related to permissions, bucket policies, etc. I think we're going to try rolling back to v1.80 to see if it corrects the problem.
kerem commented 2026-03-04 01:44:02 +03:00
Author
Owner
Copy link

@b0ku1 commented on GitHub (Aug 11, 2017):

@gkrinc Did rolling back fix the problem? Please let me know. Thanks in advance!

<!-- gh-comment-id:321750060 --> @b0ku1 commented on GitHub (Aug 11, 2017): @gkrinc Did rolling back fix the problem? Please let me know. Thanks in advance!
kerem commented 2026-03-04 01:44:02 +03:00
Author
Owner
Copy link

@baregawi commented on GitHub (Jan 15, 2019):

If this is only happening intermittently, try increasing the number of -o retries=4 or higher.

<!-- gh-comment-id:454331760 --> @baregawi commented on GitHub (Jan 15, 2019): If this is only happening intermittently, try increasing the number of `-o retries=4` or higher.
kerem commented 2026-03-04 01:44:02 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Mar 30, 2019):

We kept this issue open for a long time.
Is this problem continuing?
We launch new version 1.86, which fixed some problem(bugs).
Please use the latest version.
I will close this, but if the problem persists, please reopen or post a new issue.

If you encounter problems with s3fs as well, try using the dbglevel`` -d curldbg or similar option to print out the log.
It contains information for the solution.

<!-- gh-comment-id:478220808 --> @ggtakec commented on GitHub (Mar 30, 2019): We kept this issue open for a long time. Is this problem continuing? We launch new version 1.86, which fixed some problem(bugs). Please use the latest version. I will close this, but if the problem persists, please reopen or post a new issue. If you encounter problems with s3fs as well, try using the `dbglevel`` -d` `curldbg` or similar option to print out the log. It contains information for the solution.
kerem commented 2026-03-04 01:44:02 +03:00
Author
Owner
Copy link

@Findus1 commented on GitHub (Mar 30, 2019):

Please do not close this issue until it has been confirmed fixed.
This issue has been open for a long time because the issue has been present for a long time - for several years at least, I have had to regularly restart my S3FS mounts. I have tried every fix in this thread, and note that there are many other people with this issue.
V1.86 has not yet been released, but I will upgrade to 1.85 and let you know in a few weeks if the problem persists. Please don't close this issue without testing

<!-- gh-comment-id:478229067 --> @Findus1 commented on GitHub (Mar 30, 2019): Please do not close this issue until it has been confirmed fixed. This issue has been open for a long time because the issue has been present for a long time - for several years at least, I have had to regularly restart my S3FS mounts. I have tried every fix in this thread, and note that there are many other people with this issue. V1.86 has not yet been released, but I will upgrade to 1.85 and let you know in a few weeks if the problem persists. Please don't close this issue without testing
kerem commented 2026-03-04 01:44:02 +03:00
Author
Owner
Copy link

@ggtakec commented on GitHub (Mar 30, 2019):

@Findus1 I'm sorry and Thanks to ping.
I reopen this issue and we hope to get the result from you.
Thanks in advance for your help.

<!-- gh-comment-id:478231240 --> @ggtakec commented on GitHub (Mar 30, 2019): @Findus1 I'm sorry and Thanks to ping. I reopen this issue and we hope to get the result from you. Thanks in advance for your help.
kerem commented 2026-03-04 01:44:02 +03:00
Author
Owner
Copy link

@Findus1 commented on GitHub (Mar 30, 2019):

Thanks Takeshi,
Sorry if my reply sounded a bit grumpy - the endpoint dropping has been a
pain for years. Thanks for reopening and for your work on it. I'll post
some testing results here in a few weeks.

On Sat, 30 Mar 2019, 10:17 Takeshi Nakatani, notifications@github.com
wrote:

@Findus1 https://github.com/Findus1 I'm sorry and Thanks to ping.
I reopen this issue and we hope to get the result from you.
Thanks in advance for your help.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/s3fs-fuse/s3fs-fuse/issues/506#issuecomment-478231240,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHXjQt16xHgOuOOBSaxKtbLSSi7E_91Cks5vbzmzgaJpZM4K3_Qb
.

<!-- gh-comment-id:478231624 --> @Findus1 commented on GitHub (Mar 30, 2019): Thanks Takeshi, Sorry if my reply sounded a bit grumpy - the endpoint dropping has been a pain for years. Thanks for reopening and for your work on it. I'll post some testing results here in a few weeks. On Sat, 30 Mar 2019, 10:17 Takeshi Nakatani, <notifications@github.com> wrote: > @Findus1 <https://github.com/Findus1> I'm sorry and Thanks to ping. > I reopen this issue and we hope to get the result from you. > Thanks in advance for your help. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/s3fs-fuse/s3fs-fuse/issues/506#issuecomment-478231240>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AHXjQt16xHgOuOOBSaxKtbLSSi7E_91Cks5vbzmzgaJpZM4K3_Qb> > . >
kerem commented 2026-03-04 01:44:02 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Jul 9, 2019):

@Findus1 Transport endpoint not connected means that s3fs has exited which could be for any number of reasons. It would be better if you opened a new issue with as much context as possible, including the log flags I suggested above. Please test against the latest version 1.85 or master.

<!-- gh-comment-id:509768607 --> @gaul commented on GitHub (Jul 9, 2019): @Findus1 Transport endpoint not connected means that s3fs has exited which could be for any number of reasons. It would be better if you opened a new issue with as much context as possible, including the log flags I suggested above. Please test against the latest version 1.85 or master.
kerem commented 2026-03-04 01:44:02 +03:00
Author
Owner
Copy link

@gaul commented on GitHub (Feb 3, 2020):

Closing due to inactivity. Please reopen if symptoms persist.

<!-- gh-comment-id:581295240 --> @gaul commented on GitHub (Feb 3, 2020): Closing due to inactivity. Please reopen if symptoms persist.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
v1.97
v1.96
v1.95
v1.94
v1.93
v1.92
v1.91
v1.90
v1.89
v1.88
v1.87
v1.86
v1.85
v1.84
v1.83
v1.82
v1.81
v1.80
v1.79
v1.78
Pre-v1.78
v1.77
v1.76
v1.75
v1.74
Labels
Clear labels   
bug

   
bug

   
dataloss

   
duplicate

   
enhancement

   
feature request

   
help wanted

   
invalid

   
need info

   
performance

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question

   
testing
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/s3fs-fuse#281
No description provided.