starred/s3fs-fuse

Fork 0

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

[GH-ISSUE #2073] chgrp for mounted directory fails with Input/output error (5) #1050

New issue

Closed

opened 2026-03-04 01:50:57 +03:00 by kerem · 3 comments

kerem commented

2026-03-04 01:50:57 +03:00

Owner

Originally created by @MamataKTayade on GitHub (Dec 2, 2022).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2073

Additional Information

Version of s3fs being used (`s3fs --version`)

v1.90

Version of fuse being used (`pkg-config --modversion fuse`, `rpm -qi fuse` or `dpkg -s fuse`)

Kernel information (`uname -r`)

4.15.0-197-generic

GNU/Linux Distribution, if applicable (`cat /etc/os-release`)

[root@pod-1669828891 bin]# cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"

How to run s3fs, if applicable

[] command line
[] /etc/fstab

NA

s3fs syslog messages (`grep s3fs /var/log/syslog`, `journalctl | grep s3fs`, or `s3fs outputs`)

NA

Details about the issue

This issue was observed when using the IBM object storage class(that internally uses s3fs) on Kubernetes cluster v1.22.
The object storage is mounted inside pod like this:

Filesystem              Type       Size  Used Avail Use% Mounted on
...
s3fs                    fuse.s3fs   16E     0   16E   0% /mnt/swift/container-vol-1

The error was seen during rsync cmd being executed(from another source) targeting this directory. But, it is also reproducible by manually executing the cmd.

[root@pod-1669828891 bin]# chgrp 1001 /mnt/swift/container-vol-1
chgrp: changing group of '/mnt/swift/container-vol-1': Input/output error

[root@pod-1669828891 bin]# chgrp 1001 /mnt/swift/container-vol-1/hello.txt
[root@pod-1669828891 bin]# chgrp 1001 /mnt/swift/container-vol-1/world.txt

This works for files inside the bucket but fails for the mounted directory.
There's another similar old issue in a closed state https://github.com/s3fs-fuse/s3fs-fuse/issues/374

Just wanted to know if this is a known limitation or if this has been fixed in the new release.
Thanks.

Originally created by @MamataKTayade on GitHub (Dec 2, 2022). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2073  ### Additional Information #### Version of s3fs being used (`s3fs --version`)  v1.90 #### Version of fuse being used (`pkg-config --modversion fuse`, `rpm -qi fuse` or `dpkg -s fuse`)  #### Kernel information (`uname -r`)  4.15.0-197-generic #### GNU/Linux Distribution, if applicable (`cat /etc/os-release`)  [root@pod-1669828891 bin]# cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" #### How to run s3fs, if applicable  [] command line [] /etc/fstab  ``` NA ``` #### s3fs syslog messages (`grep s3fs /var/log/syslog`, `journalctl | grep s3fs`, or `s3fs outputs`)  ``` NA ``` ### Details about the issue  This issue was observed when using the IBM object storage class(that internally uses s3fs) on Kubernetes cluster v1.22. The object storage is mounted inside pod like this: ``` Filesystem Type Size Used Avail Use% Mounted on ... s3fs fuse.s3fs 16E 0 16E 0% /mnt/swift/container-vol-1 ``` The error was seen during rsync cmd being executed(from another source) targeting this directory. But, it is also reproducible by manually executing the cmd. ``` [root@pod-1669828891 bin]# chgrp 1001 /mnt/swift/container-vol-1 chgrp: changing group of '/mnt/swift/container-vol-1': Input/output error [root@pod-1669828891 bin]# chgrp 1001 /mnt/swift/container-vol-1/hello.txt [root@pod-1669828891 bin]# chgrp 1001 /mnt/swift/container-vol-1/world.txt ``` This works for files inside the bucket but fails for the mounted directory. There's another similar old issue in a closed state https://github.com/s3fs-fuse/s3fs-fuse/issues/374 Just wanted to know if this is a known limitation or if this has been fixed in the new release. Thanks.

kerem closed this issue

2026-03-04 01:50:57 +03:00

kerem commented

2026-03-04 01:50:58 +03:00

Author

Owner

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

@MamataKTayade I'm sorry for my late reply.
You found this problem in V1.90.
If possible, could you try the master code to see if the same problem occurs?
Some bugs have been fixed tu latest code and we would like to know if it still occurs.
Thanks in advance for your help.

@ggtakec commented on GitHub (Jan 15, 2023): @MamataKTayade I'm sorry for my late reply. You found this problem in V1.90. If possible, could you try the master code to see if the same problem occurs? Some bugs have been fixed tu latest code and we would like to know if it still occurs. Thanks in advance for your help.

kerem commented

2026-03-04 01:50:58 +03:00

Author

Owner

@MamataKTayade commented on GitHub (Jan 30, 2023):

@ggtakec Thank you. It worked on the master code and it seems the latest release 1.91 doesn't have this fix. Do you know when the next release is scheduled?

@MamataKTayade commented on GitHub (Jan 30, 2023): @ggtakec Thank you. It worked on the master code and it seems the latest release 1.91 doesn't have this fix. Do you know when the next release is scheduled?

kerem commented

2026-03-04 01:50:58 +03:00

Author

Owner

@ggtakec commented on GitHub (Jan 30, 2023):

@MamataKTayade
I can't give a definite date yet, but I'm sorting things out for the release now.
In the meantime, if you can, please try the code on the master branch.
I'll close this issue, but if you have a problem yet, please reopen this.

@ggtakec commented on GitHub (Jan 30, 2023): @MamataKTayade I can't give a definite date yet, but I'm sorting things out for the release now. In the meantime, if you can, please try the code on the master branch. I'll close this issue, but if you have a problem yet, please reopen this.

kerem referenced this issue

2026-03-04 02:02:37 +03:00

[PR #1240] [MERGED] Update ChangeLog and configure.ac for 1.86 #1883