starred/s3fs-fuse

Fork 0

mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 05:16:00 +03:00

[GH-ISSUE #563] I/O error on write, but only when mounted via fstab #316

New issue

Closed

opened 2026-03-04 01:44:20 +03:00 by kerem · 4 comments

kerem commented

2026-03-04 01:44:20 +03:00

Owner

Originally created by @Malvineous on GitHub (Apr 11, 2017).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/563

Additional Information

Version of s3fs being used (s3fs --version)
V1.80
Version of fuse being used (pkg-config --modversion fuse)
2.9.3-15+deb8u2
System information (uname -a)
Linux 820540e385ef 4.10.2-1-ARCH #1 SMP PREEMPT Mon Mar 13 17:13:41 CET 2017 x86_64 GNU/Linux
Distro (cat /etc/issue)
Debian GNU/Linux 8
s3fs command line used (if applicable)

s3fs my-bucket /mnt/s3 -o allow_other,uid=1000,gid=1000,umask=0000,default_acl="",passwd_file=/root/.aws/creds

/etc/fstab entry (if applicable):

s3fs#my-bucket /mnt/s3 fuse _netdev,allow_other,uid=1000,gid=1000,umask=0000,default_acl="",passwd_file=/root/.aws/creds  0 0

s3fs syslog messages (grep s3fs /var/log/syslog, or s3fs outputs)
None (running in Docker container)

Details about issue

I am trying to mount an S3 bucket via /etc/fstab however doing so stops me from being able to create files. If I mount the S3 bucket from the command line with the same options then it works. Why does it fail when mounted from /etc/fstab?

# cat /etc/fstab
s3fs#my-bucket /mnt/s3 fuse _netdev,allow_other,uid=1000,gid=1000,umask=0000,default_acl="",passwd_file=/root/.aws/creds  0 0

# mount /mnt/s3
# touch /mnt/s3/test
touch: cannot touch '/mnt/s3/test': Input/output error

# umount /mnt/s3
# s3fs my-bucket /mnt/s3 -o allow_other,uid=1000,gid=1000,umask=0000,default_acl="",passwd_file=/root/.aws/creds
# touch /mnt/s3/test

Originally created by @Malvineous on GitHub (Apr 11, 2017). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/563 #### Additional Information - Version of s3fs being used (s3fs --version) - V1.80 - Version of fuse being used (pkg-config --modversion fuse) - 2.9.3-15+deb8u2 - System information (uname -a) - Linux 820540e385ef 4.10.2-1-ARCH #1 SMP PREEMPT Mon Mar 13 17:13:41 CET 2017 x86_64 GNU/Linux - Distro (cat /etc/issue) - Debian GNU/Linux 8 - s3fs command line used (if applicable) ``` s3fs my-bucket /mnt/s3 -o allow_other,uid=1000,gid=1000,umask=0000,default_acl="",passwd_file=/root/.aws/creds ``` - /etc/fstab entry (if applicable): ``` s3fs#my-bucket /mnt/s3 fuse _netdev,allow_other,uid=1000,gid=1000,umask=0000,default_acl="",passwd_file=/root/.aws/creds 0 0 ``` - s3fs syslog messages (grep s3fs /var/log/syslog, or s3fs outputs) _None (running in Docker container)_ #### Details about issue I am trying to mount an S3 bucket via `/etc/fstab` however doing so stops me from being able to create files. If I mount the S3 bucket from the command line with the same options then it works. Why does it fail when mounted from `/etc/fstab`? # cat /etc/fstab s3fs#my-bucket /mnt/s3 fuse _netdev,allow_other,uid=1000,gid=1000,umask=0000,default_acl="",passwd_file=/root/.aws/creds 0 0 # mount /mnt/s3 # touch /mnt/s3/test touch: cannot touch '/mnt/s3/test': Input/output error # umount /mnt/s3 # s3fs my-bucket /mnt/s3 -o allow_other,uid=1000,gid=1000,umask=0000,default_acl="",passwd_file=/root/.aws/creds # touch /mnt/s3/test

kerem closed this issue

2026-03-04 01:44:20 +03:00

kerem commented

2026-03-04 01:44:21 +03:00

Author

Owner

@Malvineous commented on GitHub (Apr 11, 2017):

Tried also with Arch Linux, V1.80, fuse 2.9.7 and saw the same problem. No relevant errors in the logs according to journalctl -n (only one about connecting to the wrong region, which appears during both the failing fstab mount and the successful CLI mount.)

@Malvineous commented on GitHub (Apr 11, 2017): Tried also with Arch Linux, V1.80, fuse 2.9.7 and saw the same problem. No relevant errors in the logs according to `journalctl -n` (only one about connecting to the wrong region, which appears during both the failing `fstab` mount and the successful CLI mount.)

kerem commented

2026-03-04 01:44:21 +03:00

Author

Owner

@Malvineous commented on GitHub (Apr 11, 2017):

Got some logs from Arch, but they don't really explain much.

This is what happens when the FS is mounted from fstab:

[path=/test5][mode=100644]
  [tpath=/test5]
  create zero byte file object.
  URL is http://s3.amazonaws.com/my-bucket/test5
  URL changed is http://my-bucket.s3.amazonaws.com/test5
  uploading... [path=/test5][fd=-1][size=0]
  HTTP response code 400 was returned, returning EIO.
  delete stat cache entry[path=/test5]

And from the command line:

[path=/test2][mode=100644]
  [tpath=/test2]
  create zero byte file object.
  URL is http://s3-us-west-2.amazonaws.com/my-bucket/test2
  URL changed is http://my-bucket.s3-us-west-2.amazonaws.com/test2
  computing signature [PUT] [/test2] [] []
  url is http://s3-us-west-2.amazonaws.com
  uploading... [path=/test2][fd=-1][size=0]
  HTTP response code 200
  delete stat cache entry[path=/test2]
  [tpath=/test2]
  [tpath=/test2][bpath=][save=][sseckeypos=-1]
  URL is http://s3-us-west-2.amazonaws.com/my-bucket/test2
  URL changed is http://my-bucket.s3-us-west-2.amazonaws.com/test2
  computing signature [HEAD] [/test2] [] []
  url is http://s3-us-west-2.amazonaws.com
  HTTP response code 200
  add stat cache entry[path=/test2]

Looks like when mounted from fstab it's not computing the signature of files being uploaded?

@Malvineous commented on GitHub (Apr 11, 2017): Got some logs from Arch, but they don't really explain much. This is what happens when the FS is mounted from `fstab`: [path=/test5][mode=100644] [tpath=/test5] create zero byte file object. URL is http://s3.amazonaws.com/my-bucket/test5 URL changed is http://my-bucket.s3.amazonaws.com/test5 uploading... [path=/test5][fd=-1][size=0] HTTP response code 400 was returned, returning EIO. delete stat cache entry[path=/test5] And from the command line: [path=/test2][mode=100644] [tpath=/test2] create zero byte file object. URL is http://s3-us-west-2.amazonaws.com/my-bucket/test2 URL changed is http://my-bucket.s3-us-west-2.amazonaws.com/test2 computing signature [PUT] [/test2] [] [] url is http://s3-us-west-2.amazonaws.com uploading... [path=/test2][fd=-1][size=0] HTTP response code 200 delete stat cache entry[path=/test2] [tpath=/test2] [tpath=/test2][bpath=][save=][sseckeypos=-1] URL is http://s3-us-west-2.amazonaws.com/my-bucket/test2 URL changed is http://my-bucket.s3-us-west-2.amazonaws.com/test2 computing signature [HEAD] [/test2] [] [] url is http://s3-us-west-2.amazonaws.com HTTP response code 200 add stat cache entry[path=/test2] Looks like when mounted from `fstab` it's not computing the signature of files being uploaded?

kerem commented

2026-03-04 01:44:21 +03:00

Author

Owner

@ggtakec commented on GitHub (Apr 30, 2017):

@Malvineous
There seems to be a difference in URL in the two logs. (S3.amazonaws.com vs my-bucket.s3-us-west-2.amazonaws.com)
This is the difference to make you fix for pasting in the Issue (to avoid publishing the bucket name), is actually the same URL?
(There is no problem if it is the same domain name.)

There should not be any difference between booting from CLI and starting with fstab (mount command).
If it depends on communication error, is it possible to add the curldbg option and log?
Also, if you get a communication timeout, please consider the retries option.

Regards,

@ggtakec commented on GitHub (Apr 30, 2017): @Malvineous There seems to be a difference in URL in the two logs. (S3.amazonaws.com vs my-bucket.s3-us-west-2.amazonaws.com) This is the difference to make you fix for pasting in the Issue (to avoid publishing the bucket name), is actually the same URL? (There is no problem if it is the same domain name.) There should not be any difference between booting from CLI and starting with fstab (mount command). If it depends on communication error, is it possible to add the curldbg option and log? Also, if you get a communication timeout, please consider the retries option. Regards,

kerem commented

2026-03-04 01:44:21 +03:00

Author

Owner

@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.

@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.