[GH-ISSUE #1468] duplicate mounts each time `mount -a` is run #776

New issue

Open

opened 2026-03-04 01:48:41 +03:00 by kerem · 2 comments

kerem commented

2026-03-04 01:48:41 +03:00

Owner

Originally created by @nikmartin on GitHub (Nov 4, 2020).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1468

Version of s3fs being used (s3fs --version)

V1.87 (commit:38e1eaa) with OpenSSL

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

2.9.9

Kernel information (uname -r)

5.4.0-1024-aws

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

Ubuntu 20.04.1 LTS

/etc/fstab entry, if applicable

[S3-FOLDER-NAME]:/myusername /home/myusername/uploads fuse.s3fs _netdev,endpoint=us-east-2,url=https://s3-us-east-2.amazonaws.com,iam_role=auto,uid=1002,gid=1001 0 0

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

if you execute s3fs with dbglevel, curldbg option, you can get detail debug messages

Nov  4 04:14:55 ip-172-31-43-113 s3fs[44313]: Loaded mime information from /etc/mime.types
Nov  4 04:14:55 ip-172-31-43-113 s3fs[44315]: init v1.87(commit:38e1eaa) with OpenSSL
Nov  4 04:14:55 ip-172-31-43-113 s3fs[44320]: Loaded mime information from /etc/mime.types
Nov  4 04:14:55 ip-172-31-43-113 s3fs[44321]: init v1.87(commit:38e1eaa) with OpenSSL
Nov  4 04:14:56 ip-172-31-43-113 s3fs[44327]: Loaded mime information from /etc/mime.types
Nov  4 04:14:56 ip-172-31-43-113 s3fs[44328]: init v1.87(commit:38e1eaa) with OpenSSL
Nov  4 04:14:56 ip-172-31-43-113 s3fs[44333]: Loaded mime information from /etc/mime.types
Nov  4 04:14:56 ip-172-31-43-113 s3fs[44334]: init v1.87(commit:38e1eaa) with OpenSSL
Nov  4 04:14:56 ip-172-31-43-113 s3fs[44340]: Loaded mime information from /etc/mime.types
Nov  4 04:14:56 ip-172-31-43-113 s3fs[44341]: init v1.87(commit:38e1eaa) with OpenSSL
Nov  4 04:14:56 ip-172-31-43-113 s3fs[44346]: Loaded mime information from /etc/mime.types
Nov  4 04:14:56 ip-172-31-43-113 s3fs[44352]: init v1.87(commit:38e1eaa) with OpenSSL

Details about issue

With the above fstab entry, each time I run mount -a, a new mount is created:

$> mount
s3fs on /home/myusername /uploads type fuse.s3fs (rw,relatime,user_id=0,group_id=0)
s3fs on /home/myusername /uploads type fuse.s3fs (rw,relatime,user_id=0,group_id=0)
s3fs on /home/myusername /uploads type fuse.s3fs (rw,relatime,user_id=0,group_id=0)
s3fs on /home/myusername /uploads type fuse.s3fs (rw,relatime,user_id=0,group_id=0)

This looks like the same issue as #981, but I'm not using the nonempty option in fstab. I have two entries in fstab to mount two folders in the same bucket, and both mounts get duplicated each time mount -a is run

Originally created by @nikmartin on GitHub (Nov 4, 2020). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1468 #### Version of s3fs being used (s3fs --version) V1.87 (commit:38e1eaa) with OpenSSL #### Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse, dpkg -s fuse) 2.9.9 #### Kernel information (uname -r) 5.4.0-1024-aws #### GNU/Linux Distribution, if applicable (cat /etc/os-release) Ubuntu 20.04.1 LTS #### /etc/fstab entry, if applicable ``` [S3-FOLDER-NAME]:/myusername /home/myusername/uploads fuse.s3fs _netdev,endpoint=us-east-2,url=https://s3-us-east-2.amazonaws.com,iam_role=auto,uid=1002,gid=1001 0 0 ``` #### s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs) _if you execute s3fs with dbglevel, curldbg option, you can get detail debug messages_ ``` Nov 4 04:14:55 ip-172-31-43-113 s3fs[44313]: Loaded mime information from /etc/mime.types Nov 4 04:14:55 ip-172-31-43-113 s3fs[44315]: init v1.87(commit:38e1eaa) with OpenSSL Nov 4 04:14:55 ip-172-31-43-113 s3fs[44320]: Loaded mime information from /etc/mime.types Nov 4 04:14:55 ip-172-31-43-113 s3fs[44321]: init v1.87(commit:38e1eaa) with OpenSSL Nov 4 04:14:56 ip-172-31-43-113 s3fs[44327]: Loaded mime information from /etc/mime.types Nov 4 04:14:56 ip-172-31-43-113 s3fs[44328]: init v1.87(commit:38e1eaa) with OpenSSL Nov 4 04:14:56 ip-172-31-43-113 s3fs[44333]: Loaded mime information from /etc/mime.types Nov 4 04:14:56 ip-172-31-43-113 s3fs[44334]: init v1.87(commit:38e1eaa) with OpenSSL Nov 4 04:14:56 ip-172-31-43-113 s3fs[44340]: Loaded mime information from /etc/mime.types Nov 4 04:14:56 ip-172-31-43-113 s3fs[44341]: init v1.87(commit:38e1eaa) with OpenSSL Nov 4 04:14:56 ip-172-31-43-113 s3fs[44346]: Loaded mime information from /etc/mime.types Nov 4 04:14:56 ip-172-31-43-113 s3fs[44352]: init v1.87(commit:38e1eaa) with OpenSSL ``` ### Details about issue With the above fstab entry, each time I run mount -a, a new mount is created: ``` $> mount s3fs on /home/myusername /uploads type fuse.s3fs (rw,relatime,user_id=0,group_id=0) s3fs on /home/myusername /uploads type fuse.s3fs (rw,relatime,user_id=0,group_id=0) s3fs on /home/myusername /uploads type fuse.s3fs (rw,relatime,user_id=0,group_id=0) s3fs on /home/myusername /uploads type fuse.s3fs (rw,relatime,user_id=0,group_id=0) ``` This looks like the same issue as #981, but I'm not using the nonempty option in fstab. I have two entries in fstab to mount two folders in the same bucket, and both mounts get duplicated each time mount -a is run

kerem added the

enhancement

label

2026-03-04 01:48:41 +03:00

kerem commented

2026-03-04 01:48:42 +03:00

Author

Owner

@remizyaka commented on GitHub (Nov 23, 2023):

Have the same issue. Any news on how it can be fixed?

@remizyaka commented on GitHub (Nov 23, 2023): Have the same issue. Any news on how it can be fixed?

kerem commented

2026-03-04 01:48:42 +03:00

Author

Owner

@ggtakec commented on GitHub (Feb 12, 2024):

I don't see any way to prevent this problem.
With the current fuse2, there seems to be no countermeasure other than specifying nonempty.

Since the nonempty option is no longer available in fuse3, I feel that some kind of countermeasure is needed to prevent this problem in fuse3.
If the currently running mount point in s3fs can be shared between processes(using common files, shared SHM, etc.), it may be possible to cause processes to start later to fail.
Alternatively, you need to prepare a dedicated option equivalent to nonempty.

We need to be considering something for this problem to support fuse3.

@ggtakec commented on GitHub (Feb 12, 2024): I don't see any way to prevent this problem. With the current fuse2, there seems to be no countermeasure other than specifying `nonempty`. Since the `nonempty` option is **no longer** available in fuse3, I feel that some kind of countermeasure is needed to prevent this problem in fuse3. If the currently running mount point in s3fs can be shared between processes(using common files, shared SHM, etc.), it may be possible to cause processes to start later to fail. Alternatively, you need to prepare a dedicated option equivalent to `nonempty`. We need to be considering something for this problem to support fuse3.