blobfuse2 returns with success (exit 0) before filesystem mount is complete when started through autofs

[fsorenson]

When autofs initiates a mount, blobfuse2 reports an error:

blobfuse2[408325] : [1][/mnt/blobfuse2/storage1] LOG_DEBUG [utils.go (168)]: SDK(Retry) : response 200
blobfuse2[408325] : [1][/mnt/blobfuse2/storage1] LOG_DEBUG [utils.go (168)]: SDK(Retry) : exit due to non-retriable status code
blobfuse2[408325] : [1][/mnt/blobfuse2/storage1] LOG_INFO [mount.go (509)]: mount: Mounting blobfuse2 on /mnt/blobfuse2/storage1
blobfuse2[408325] : [1][/mnt/blobfuse2/storage1] LOG_ERR [mount.go (547)]: mount : failed to daemonize application [daemon: Resource temporarily unavailable], trying auto cleanup
blobfuse2[408325] : [1][/mnt/blobfuse2/storage1] LOG_DEBUG [mount.go (556)]: mount: foreground disabled, child = false

It then exits with success (0), but another thread continues to execute.

autofs interprets the exit code 0 as a successful mount.

However, since since blobfuse2 hasn't completed the mount yet, autofs is again triggered to start another mount.

After just shy of 22 seconds, there are 3-4 blobfuse2 processes executing, and the filesystem is mounted 3-4 times.

At this point, the mount works fine.

What is needed to fix the 'failed to daemonize application', eliminate the early exit before the filesystem is ready, and cut the mount time?

autofs configuration:
/etc/auto.master:
/mnt/blobfuse2 /etc/auto.blobfuse2 --timeout=60

/etc/auto.blobfuse2:
storage1 -fstype=fuse :blobfuse2\#--config-file=/etc/blobfuse2_config.yaml

# systemctl restart autofs

# time cat /mnt/blobfuse2/storage1/testfile
testfile
real 0m21.837s
user 0m0.000s
sys 0m0.003s

blobfuse2 is latest git, system is Red Hat Enterprise Linux 9 with latest available autofs

attaching config file and logfile containing blobfuse2 trace and autofs messages

[fsorenson]

debug.txt
blobfuse2_config.yaml.txt

[vibhansa-msft]

'failed to daemonize application' means there is some stale state left from previous mount. There are some housekeeping files that blobfuse creates at $HOME/.blobfuse. You can clean up this folder manually and retry. On every successful unmount it will automatically cleanup the state. But if node terminates abruptly or in cases of crash sometimes this stale state is left over.

[raven-au]

'failed to daemonize application' means there is some stale state left from previous mount.

I'm not sure Frank's description focuses on what's causing autofs to get confused.
The daemonize message may need attention but first, if I understand the blobfuse utility correctly, blobfuse2 returns success immediately, before the mount completes. Is that right or is it in fact the daemonize failure that is causing it to not wait for mount completion?
Note that because autofs receives mount requests from the kernel and the automount daemon runs as the root user (since mount is privileged) the mount will be performed as root. So a user will not be able to clean the context up.

[raven-au]

Or is it the earlier:

LOG_DEBUG [health-monitor.go (102)]: health-monitor : Starting health-monitor for blobfuse2 pid = 408315

LOG_ERR [mount.go (730)]: Mount::startMonitor : [failed to start health monitor [exec: "bfusemon": executable file not found in $PATH]]

Where should "bfusemon" be located?
Is there a monitor process for every mount?

[fsorenson]

I made sure everything was unmounted, no running processes, commented out health monitor lines, removed all files from /root/.blobfuse2, and re-tested.

I get the same result; the process appears to return before the mount is available, so automount gets triggered again. This resulted in 4 processes, the 2nd-4th reported the 'failed to daemonize' (which makes sense, since the first process was still running).

Looking through the debug output, this timeout looks relevant:
Wed Feb 11 20:50:31.886 UTC 2026 : blobfuse2[1947937] : [1][/mnt/blobfuse2/storage1] LOG_DEBUG [mount.go (556)]: mount: foreground disabled, child = false

Wed Feb 11 20:50:36.889 UTC 2026 : blobfuse2[1947937] : [1][/mnt/blobfuse2/storage1] LOG_INFO [mount.go (617)]: mount: Child [1947944 : /mnt/blobfuse2/storage1] status check timeout

It's immediately after this that the automount process reaps the child process, and thinks the filesystem is mounted. But since it's not yet responding, automount again attempts to mount, starting up another blobfuse2 process.

So yes, it looks like I've misidentified the cause of the problem as being related to the failure to daemonize and the error related to the state file.

Ultimately, the automount program is expecting to reap the child process once the mount is successful, but blobfuse2 appears to time out while waiting for a child process, and returns error code 0, while the child process continues on.

debug.txt

[raven-au]

Thanks Frank,

It's important to understand that the Linux VFS path resolution enters a loop when it encounters a mount point (actually there's bit more going on there) to follow the path into the mounted file system. In the case of an autofs directory, before it follows the mount it may send a mount request to the automount daemon which blocks the walk until the mount is completed so the VFS can then follow the mount.

Clearly Linux VFS path resolution requires mounts to be present when they are encountered during a path walk so in the case of autofs anything that performs this mount must complete the mount before returning and return an appropriate completion status (success or failure).

Can something be done so that blobfuse2 behaves this way please.

[syeleti-msft]

Hi @fsorenson , @raven-au

blobfuse2 returns success immediately, before the mount completes. Is that right or is it in fact the daemonize failure that is causing it to not wait for mount completion?

we spawn a child process and wait for it complete the mount and parent waits for a signal. but in the case of not getting any signal from child, we timeout in 5 seconds and return success for the mount process. In general, 5 seconds is something we saw work in most of the scenarios.

from the logs, this is what I observed happening.

Wed Feb 11 20:50:31.886 UTC 2026 : blobfuse2[1947937] : [1][/mnt/blobfuse2/storage1] LOG_DEBUG [mount.go (556)]: mount: foreground disabled, child = false
Wed Feb 11 20:50:36.889 UTC 2026 : blobfuse2[1947937] : [1][/mnt/blobfuse2/storage1] LOG_INFO [mount.go (617)]: mount: Child [1947944 : /mnt/blobfuse2/storage1] status check timeout

...

Wed Feb 11 20:50:37.264 UTC 2026 : blobfuse2[1947944] : [1][/mnt/blobfuse2/storage1] LOG_CRIT [mount.go (477)]: Starting Blobfuse2 Mount : 2.5.2 on [Red Hat Enterprise Linux 9.7 (Plow)]

the child process[pid: 1947944] which is responsible for the mount has started just after the timeout has elapsed. hence you saw some undefined behavior.

to mitigate the issue, you can configure this CLI parameter to let tell parent process to wait for more time

--wait-for-mount= : Let parent process wait for given timeout before exit to ensure child has started.

eg: --wait-for-mount=10
pls configure it to >=10s
as for some reason spawning a new child process is taking more time in your machine, any idea why?
are you facing the same issue while mounting without the autofs as well?