mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 21:35:58 +03:00
[GH-ISSUE #1383] Erroneous "file not found" issues after reboot or remount #740
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#740
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ferricoxide on GitHub (Sep 2, 2020).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1383
Additional Information
The following information is very important in order to help us to help you. Omission of the following details may delay your support request or receive no attention at all.
Keep in mind that the commands we provide to retrieve information are oriented to GNU/Linux Distributions, so you could need to use others if you use s3fs on macOS or BSD
Version of s3fs being used (s3fs --version)
Started with: 1.85 (locally staged version)
Updated to: 1.86 (from EPEL)
Finally: 1.87 (compiled from source retrieved from GitHub)
Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse, dpkg -s fuse)
fuse-2.9.2-11.el7.x86_64
Kernel information (uname -r)
3.10.0-1127.18.2.el7.x86_64
GNU/Linux Distribution, if applicable (cat /etc/os-release)
NAME="Red Hat Enterprise Linux Server"
VERSION="7.8 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.8"
PRETTY_NAME="Red Hat Enterprise Linux"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.8:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.8
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.8"
s3fs command line used, if applicable
Not directly applicable: issues experienced with OS commands
/etc/fstab entry, if applicable
Not applicable: using mount from
/etc/rc.d/rc.local:s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs)
Details about issue
After a system reboot (also reproducible by
umounting and remounting the bucket/folder), cannot directly access files hosted within an s3fs-based mount. Have to "prime" the mount, first (e.g., executing anls /<S3FS>/<MOUNT>/<POINT>prior to trying to directly-access desired file(s)). The above logging output was produced having done:@ferricoxide commented on GitHub (Sep 9, 2020):
In further messing around with the problem, I found:
Reset s3fs mount to “starting” state:
Check if can immediately reference target file:
Try to use
filecommand against “/dsw/tmp/installer/packages” to prime the mount:Check if can now directly-reference target file:
Try to use
lscommand against “/dsw/tmp/installer/packages” (fully-qualified path) to prime the mount:Check if can now directly-reference target file:
Try to use
lscommand against “packages” (relative path) to prime the mount:Check if can now directly-reference target file:
Try to use
lscommand against directory’s root-inode (relative path) to prime the mount:Check if can now directly-reference target file:
Check to see what OS thinks the “/dsw/tmp/installer/packages” directory-object is:
Basically, before successfully "priming" the s3fs mount, the
/dsw/tmp/installer/packagesfile-object gets misidentified as a ZIP file rather than a directory-inode.@WencongXiao commented on GitHub (Sep 18, 2020):
any update about this issue? Do you solve it? I also meet a similar problem.
@gaul commented on GitHub (Oct 10, 2020):
I wonder if this is a timing issue, e.g., it takes s3fs a while to mount the path? If you wait 60 seconds can you see the files that you expect?
@ferricoxide commented on GitHub (Oct 12, 2020):
@WencongXiao
No. And looks like no one on the project has processed this issue, yet.
@gaul
Negative. The only way to get the files to show up is to traverse into the directory (as previously illustrated).