[GH-ISSUE #2143] Add support for systemd mount units #1094

New issue

Closed

opened 2026-03-04 01:51:20 +03:00 by kerem · 1 comment

kerem commented

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

Owner

Originally created by @guss77 on GitHub (Mar 27, 2023).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2143

Additional Information

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

1.90

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

2.9.9

Kernel information (`uname -r`)

5.19.0-38-generic

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

PRETTY_NAME="KDE neon Unstable Edition"
NAME="KDE neon"
VERSION_ID="22.04"
VERSION="Unstable Edition"
VERSION_CODENAME=jammy
ID=neon
ID_LIKE="ubuntu debian"
HOME_URL="https://neon.kde.org/"
SUPPORT_URL="https://neon.kde.org/"
BUG_REPORT_URL="https://bugs.kde.org/"
PRIVACY_POLICY_URL="https://kde.org/privacypolicy/"
UBUNTU_CODENAME=jammy

How to run s3fs, if applicable

I want to use a systemd mount unit to mount the S3 file system. My best attempt so far is as follows:

~/.config/systemd/user/home-odeda-mnt-s3.mount:

[Unit]
Description=My S3 bucket

[Mount]
What=my-bucket
Where=%h/mnt/s3
Options=use_path_request_style,profile=myprofile
Type=fuse.s3fs

which does call onto s3fs, but the problem is that systemd understands the what as a relative path name and it canonicalize it as %h/my-bucket before submitting it to s3fs (for some reason - I'm not sure why), which results in the following log:

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

Mar 27 15:04:19 vesho s3fs[2728865]: s3fs version 1.90(unknown) : s3fs -o rw,use_path_request_style,profile=myprofile,dev,suid /home/odeda/my-bucket /home/odeda/mnt/s3
Mar 27 15:04:19 vesho s3fs[2728865]: Loaded mime information from /etc/mime.types
Mar 27 15:04:19 vesho s3fs[2728865]: s3fs: BUCKET /home/odeda/my-bucket -- bucket name contains an illegal character.
Mar 27 15:04:19 vesho systemd[2805]: home-odeda-mnt-s3.mount: Mount process exited, code=exited, status=1/FAILURE
Mar 27 15:04:19 vesho systemd[2805]: home-odeda-mnt-s3.mount: Failed with result 'exit-code'.

Details about issue

It would be great if s3fs can be configured (using an option?) or auto-detect that it is called in such a weird way and workaround the issue.

One possible solution that I though might make sense is to specify the What field as an S3 url (s3://my-bucket) - in such a case systemd "understands" that this is a network path and doesn't rewrite it, causing the following s3fs log:

Mar 27 15:07:37 vesho s3fs[2736490]: s3fs version 1.90(unknown) : s3fs -o rw,use_path_request_style,profile=myprofile,dev,suid s3://my-bucket /home/odeda/mnt/s3
Mar 27 15:07:37 vesho s3fs[2736490]: s3fs: unable to access MOUNTPOINT s3://my-bucket: No such file or directory
Mar 27 15:07:37 vesho systemd[2805]: home-odeda-mnt-s3.mount: Mount process exited, code=exited, status=1/FAILURE
Mar 27 15:07:37 vesho systemd[2805]: home-odeda-mnt-s3.mount: Failed with result 'exit-code'.

But if s3fs can be taught to ignore the s3:// prefix, that would allow this configuration to work.

Originally created by @guss77 on GitHub (Mar 27, 2023). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2143 ### Additional Information #### Version of s3fs being used (`s3fs --version`) 1.90 #### Version of fuse being used (`pkg-config --modversion fuse`, `rpm -qi fuse` or `dpkg -s fuse`) 2.9.9 #### Kernel information (`uname -r`) 5.19.0-38-generic #### GNU/Linux Distribution, if applicable (`cat /etc/os-release`) PRETTY_NAME="KDE neon Unstable Edition" NAME="KDE neon" VERSION_ID="22.04" VERSION="Unstable Edition" VERSION_CODENAME=jammy ID=neon ID_LIKE="ubuntu debian" HOME_URL="https://neon.kde.org/" SUPPORT_URL="https://neon.kde.org/" BUG_REPORT_URL="https://bugs.kde.org/" PRIVACY_POLICY_URL="https://kde.org/privacypolicy/" UBUNTU_CODENAME=jammy #### How to run s3fs, if applicable I want to use a systemd mount unit to mount the S3 file system. My best attempt so far is as follows: `~/.config/systemd/user/home-odeda-mnt-s3.mount`: ``` [Unit] Description=My S3 bucket [Mount] What=my-bucket Where=%h/mnt/s3 Options=use_path_request_style,profile=myprofile Type=fuse.s3fs ``` which does call onto s3fs, but the problem is that systemd understands the `what` as a relative path name and it canonicalize it as `%h/my-bucket` before submitting it to `s3fs` (for some reason - I'm not sure why), which results in the following log: #### s3fs syslog messages (`grep s3fs /var/log/syslog`, `journalctl | grep s3fs`, or `s3fs outputs`) ``` Mar 27 15:04:19 vesho s3fs[2728865]: s3fs version 1.90(unknown) : s3fs -o rw,use_path_request_style,profile=myprofile,dev,suid /home/odeda/my-bucket /home/odeda/mnt/s3 Mar 27 15:04:19 vesho s3fs[2728865]: Loaded mime information from /etc/mime.types Mar 27 15:04:19 vesho s3fs[2728865]: s3fs: BUCKET /home/odeda/my-bucket -- bucket name contains an illegal character. Mar 27 15:04:19 vesho systemd[2805]: home-odeda-mnt-s3.mount: Mount process exited, code=exited, status=1/FAILURE Mar 27 15:04:19 vesho systemd[2805]: home-odeda-mnt-s3.mount: Failed with result 'exit-code'. ``` ### Details about issue It would be great if s3fs can be configured (using an option?) or auto-detect that it is called in such a weird way and workaround the issue. One possible solution that I though might make sense is to specify the `What` field as an S3 url (`s3://my-bucket`) - in such a case systemd "understands" that this is a network path and doesn't rewrite it, causing the following s3fs log: ``` Mar 27 15:07:37 vesho s3fs[2736490]: s3fs version 1.90(unknown) : s3fs -o rw,use_path_request_style,profile=myprofile,dev,suid s3://my-bucket /home/odeda/mnt/s3 Mar 27 15:07:37 vesho s3fs[2736490]: s3fs: unable to access MOUNTPOINT s3://my-bucket: No such file or directory Mar 27 15:07:37 vesho systemd[2805]: home-odeda-mnt-s3.mount: Mount process exited, code=exited, status=1/FAILURE Mar 27 15:07:37 vesho systemd[2805]: home-odeda-mnt-s3.mount: Failed with result 'exit-code'. ``` But if s3fs can be taught to ignore the `s3://` prefix, that would allow this configuration to work.