4.41.2 (191736) - bundled virtiofsd outdated; doesn't allow for passing on arguments #289

Activity

1. CPioGH2002

   added

   needs-triage

   on May 30, 2025
2. bsousaa

   assigned

   KatTomrushka

   and

   BasiaFusinska

   on May 30, 2025
3. CPioGH2002 commented on May 31, 2025

   

   CPioGH2002

   on May 31, 2025

   Last edited by CPioGH2002

   Author

   More actions

   Expanding: Trying to make the wrapper script work

   First, I checked if Docker Desktop for Linux respects my system-wide PATH setup:

   echo $PATH
   /home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
   

   /usr/local/bin$ ll
   
   -rwxr-xr-x  1 root root     85 May 31 07:28 virtiofsd*
   

   /usr/local/bin$ cat virtiofsd 
   #!/bin/sh
   exec /opt/docker-desktop/bin/virtiofsd --inode-file-handles=mandatory "$@"
   

   opt/docker-desktop/bin$ ll
   
   -rwxr-xr-x 1 root root   3189440 May  6 10:36 virtiofsd*
   

   To my understanding, any wrapper script for virtiofsd being placed at /usr/local/bin and named "virtiofsd" should be called before the actual virtiofsd file if the PATH setup is respected. But if Docker Desktop calls up the file at /opt/docker-desktop/bin/ directly, the wrapper script will be disregarded.

   I checked via ps aux | grep virtiofsd (to see the path in use and if the --inode-file-handles=mandatory argument shows up) and also ran my typical test container, the one with the heavy IO, just in case.

   Turns out that the latter scenario is in place, with the system-wide PATH setup not being in effect regarding the calls for virtiofsd by Docker Desktop for Linux. By this, --inode-file-handles=mandatory doesn't get applied, leading to the results described before.

   Other attempts

   1) Directly replacing the original virtiofsd file Docker uses (at opt/docker-desktop/bin) with the one for the script (which then points to the renamed original file) -> leads to Docker Engine failing to start.

   Script contents in that case:

   #!/bin/sh
   exec /opt/docker-desktop/bin/virtiofsd.ORI --inode-file-handles=mandatory "$@"
   

   2)
   a) Trying to set an environment variable to make sure the call for virtiofsd encounters my wrapper script first -> There's no dialog in the Docker Desktop GUI to allow for that.

   b) Launching Docker Desktop directly via the terminal with the added PATH value (PATH=$PATH:/usr/local/bin /opt/docker-desktop/bin/docker-desktop) -> does not lead to my script being used

   3) Trying the same as in 2) but via Docker Desktop's settings file at ~/.docker/desktop/settings-store.json -> Any edits I made there either didn't apply or led to Docker Desktop refusing to start.

   4) Trying to pass on commands when running containers which would lead to Docker Desktop for Linux calling my wrapper script instead of the virtiofsd file directly -> No luck with that since only the environment of the container would be affected, not the one Docker Desktop itself runs in.

   Non-script-based approach

   I shortly tried to externally launch virtiofsd with the parameters and settings I need, to then launch Docker Desktop in the hope to "pick up" the socket, which it didn't do though. On that point, I will happily admit that the method is very new to me, so I could have made mistakes along the way.

   Conclusions (of the layman I am)

   1. The path to the virtiofsd file is hard-coded in Docker Desktop for Linux. Hence the disregard of any global or individually issued PATH setting.
   2. A replacement of the virtiofsd file (with a wrapper script) in the folder Docker Desktop uses seems to upset things in a way which causes Docker Engine failing to start.
   3. As the "call" for virtiofsd being made by Docker Desktop cannot be amended with an argument (like --inode-file-handles=mandatory), only the default mode of virtiofsd is used, which in turn leads to the problems mentioned with heavy IO tasks.
4. CPioGH2002 commented on Jun 9, 2025

   

   CPioGH2002

   on Jun 9, 2025

   Last edited by CPioGH2002

   Author

   More actions

   On a tangent, it's interesting to see that people tend to recommend leaving Docker Desktop for Linux alone and sticking to the normal Docker setup, perhaps with third-party extensions like Portainer. Recent example: https://www.reddit.com/r/docker/comments/1l6er6v/docker_desktop_vs_engine_with_gui/

   Given the problems arising from the VM setup, the inability to currently alter underlying mechanics (like virtiofsd parameters) and the amount of support (if present at all, albeit for the free tier), once would indeed concur.

   Anyhow, if the virtiofsd-based problems mentioned in this thread ever clear up or at least receive some dev input, I would certainly welcome it. In the meantime, I shall uninstall Docker Desktop for Linux and go with the normal release of Docker. Not sure if that's the intended result. It's a shame since Docker Desktop certainly took some time to develop.

   ---

   Edit: After re-reading my post, I noticed that it comes across way more passive-aggressive as intended. So please don't read in that tone/mood, but still notice that some parts of the Docker community already made up their mind about Docker Desktop on Linux, for one reason or another.
5. CPioGH2002 commented on Jun 11, 2025

   

   CPioGH2002

   on Jun 11, 2025

   Author

   More actions

   Update on getting rid of Docker Desktop for Linux and running the same task with Docker Engine: Even my heavy IO tasks now finish in no time and without errors or RAM exhaustion.

   In some sense, this is good (as I am able to actually create some output) but also sad since one has to leave the otherwise nice looking and useful Docker Desktop GUI behind. Not sure if that's the desired outcome in the eyes of the company but, as mentioned before, there seems to be a certain consensus among Linux users to prefer Docker Engine over Docker Desktop at any given time.

   Since beginners might fall for the appeal of the GUI while later encountering the possible errors due to the "VM" approach Docker Desktop uses (as opposed to the "direct" one by Docker Engine), mentioned consensus does seem to make sense. And if one wanted to add GUI elements, third parties are ready to help.

   In short: If Docker Desktop (on Linux) causes problems, try Docker Engine and stick with it.
6. Xeeynamo

   self-assigned this

   on Jun 18, 2025
7. Xeeynamo

   added

   status/acknowledged

   and removed

   needs-triage

   on Jun 18, 2025
8. Xeeynamo commented on Jun 18, 2025

   

   Xeeynamo

   on Jun 18, 2025

   More actions

   Hey @CPioGH2002 thanks for the report! We're planning to ship Docker Desktop 4.43.0 with virtiofsd v1.13.1, which includes improvements in IOPS performance. While we’re aware that v1.13.2 is now available, we still need to complete internal performance and stability testing before considering its integration.

   But if Docker Desktop calls up the file at /opt/docker-desktop/bin/ directly, the wrapper script will be disregarded.

   Yes, that’s expected behavior. Docker Desktop bundles specific versions of dependencies like virtiofsd to ensure consistent performance and compatibility across various Linux distributions. For example, Ubuntu Plucky Puffin includes v1.13.0, Arch Linux uses v1.13.1, etc. By shipping our own version, we maintain a known baseline across all environments.

   If you want to use a custom wrapper to tweak the virtiofsd arguments, one workaround could be creating a symbolic link that replaces the bundled virtiofsd with your script, which then calls the latest /usr/local/bin/virtiofsd installed on your Linux distro.

   👍React with 👍1Reacted by CPioGH2002
9. CPioGH2002 commented on Jun 18, 2025

   

   CPioGH2002

   on Jun 18, 2025

   Last edited by CPioGH2002

   Author

   More actions

   Thanks for your answer, much appreciated.

   Hearing that a more recent version of virtiofsd will be shipped is great news.

   Did you see which methods I used to make the wrapper script work? I posted the results above and had no luck getting Docker Desktop for Linux to work with any of them. Docker Engine then simply fails to start.

   Edit: To my understanding, the No.1 method I used (described above) is very similar to what you are proposing: In both cases, Docker Engine encounters either my wrapper script directly or a symlink to my wrapper script. I would envision that the results are the same in both cases = Docker Engine failing to start.

   Please correct me if I'm wrong. I might try installing and testing Docker Desktop for Linux again then.

   Edit2: I tried your advice, see the outcome below.

   Regarding virtiofsd arguments in general: virtiofsd allows for some very useful options, especially for heavy IO tasks. If those could be implemented into Docker Desktop directly, nobody would need a workaround. Simply exposing the options (via an "extra commands" field or something) would already help.
10. CPioGH2002 commented on Jun 19, 2025

    

    CPioGH2002

    on Jun 19, 2025

    Author

    More actions

    Following your advice

    If you want to use a custom wrapper to tweak the virtiofsd arguments, one workaround could be creating a symbolic link that replaces the bundled virtiofsd with your script, which then calls the latest /usr/local/bin/virtiofsd installed on your Linux distro.

    Setup

    I went about it this way:

    # checking presence and permissions of the system-wide install of virtiofsd
    /usr/libexec$ ll
    -rwxr-xr-x  1 root root 3480240 Jan 14 17:33 virtiofsd*
    
    # checking presence and contents of the wrapper script created
    /usr/local/bin$ ll
    -rwxr-xr-x  1 root root     74 Jun 19 22:23 virtiofsd*
    
    cat virtiofsd 
    #!/bin/sh
    exec /usr/libexec/virtiofsd --inode-file-handles=mandatory "$@"
    
    # creating symlink
    sudo ln -s /usr/local/bin/virtiofsd /opt/docker-desktop/bin/virtiofsd
    
    # checking presence and permissions of the symlink, notice the backup of the original file
    /opt/docker-desktop/bin$ ll
    lrwxrwxrwx 1 root root        24 Jun 19 22:27 virtiofsd -> /usr/local/bin/virtiofsd*
    -rwxr-xr-x 1 root root   3262752 Jun 13 20:37 virtiofsd.BAK*
    

    Result

    Docker Engine (in Docker Desktop for Linux) refusing to start with:

    running engine: waiting for the VM setup to be ready: running filesharing: running virtiofsd for /media/user/1TBSSD/: exit status 2

    The directory mentioned is the one I set up as shared folder. It's present and available for the host OS. It's the same I used for other VMs on the system and with Docker Engine (stand-alone install) before, where it worked fine.

    Conclusion

    Unless I did something wrong and/or misunderstood your advice, the conclusion remains that the wrapper script isn't accepted. As for other methods I tried before this one, I'd refer to one of my previous posts.