VSCodium File Dialog Automount Issue on Manjaro KDE

jackdinn · 17 March 2025 02:53

Hi everyone,

I’m experiencing an issue with VSCodium on my Manjaro KDE system that I haven’t been able to resolve despite trying several workarounds. When I open the file dialog (e.g., to open a folder), it hangs for an extended period (a minute on every click). After some digging, I’ve discovered that the delay is caused by the file dialog triggering an automount of one of my NAS shares.

The Issue

My file dialog’s sidebar shows several network shares (configured for automount via systemd). The first share in the sidebar (//192.168.1.100/manjaro-home) is not mounted at the time the dialog opens, so xdg‑desktop‑portal attempts to mount it automatically. This mount attempt fails (error code –113 from CIFS), causing a significant delay. If I remove or rearrange the share, the portal simply moves on to the next unmounted share, so the problem persists.

I cannot pre-mount these shares because I rely on their automount behavior for my backup system and overall workflow in Dolphin.

What I’ve Tried

GPU-Related Flags:

Launched VSCodium with --disable-gpu (and also tried with --disable-gpu-sandbox) to rule out GPU rendering issues.
Verified the process shows the flag, and it initially worked—but then later the file dialog still hung.

Environment Variables for Portals:

Tried setting GTK_USE_PORTAL=0 before launching VSCodium (i.e., GTK_USE_PORTAL=0 codium --disable-gpu), but the file dialog’s GUI did not change.
ELECTRON_USE_DESKTOP_PORTAL=0 codium --disable-gpu, which still resulted in the same native file dialog with automount behavior.

Logging & Configuration Reset:

Enabled Electron logging with ELECTRON_ENABLE_LOGGING=1 (capturing logs to a file) to check for errors related to the file dialog, but no relevant messages appeared.
Cleared all VSCodium settings and extensions to eliminate any potential conflicts.

System & Automount Checks:

Confirmed that xdg-desktop-portal and xdg-desktop-portal-kde are up to date and running.
Verified that the automount is triggered by xdg‑desktop‑portal when the file dialog opens—visible in the system logs (CIFS mount errors for the NAS share).

System Details

inxi -b

❱ inxi -b
System:
Host: greg-venusseries Kernel: 6.13.5-2-MANJARO arch: x86_64 bits: 64
Desktop: KDE Plasma v: 6.3.2 Distro: Manjaro Linux
Machine:
Type: Desktop System: Micro (HK) Tech product: Venus Series
Mobo: Shenzhen Meigao Equipment model: AHWSA, UEFI: American Megatrends LLC. v: AHWSA.1.22 (03/12/2024)
CPU:
14-core (6-mt/8-st) 13th Gen Intel Core i9-13900H
Graphics:
Intel Raptor Lake-P [Iris Xe Graphics] (driver: i915)
Display: X.Org (Xwayland) with modesetting, 3840x2160@60Hz
Network:
Intel Ethernet I226-V, MEDIATEK MT7922 802.11ax PCIe Wireless
Drives:
Local Storage: 1.84 TiB total, 323.1 GiB used
Memory:
32 GiB total, ~31 GiB available

❱ codium --version
1.98.2
c6b0b68cdb1a0ec15f1eb97d903aa1855445fd42
x64

Summary

Problem: Opening the VSCodium file dialog hangs due to the automount attempt of my NAS share (//192.168.1.100/manjaro-home) by xdg‑desktop‑portal.

Impact: Significant delays in the file dialog (every click in it, even closing it), affecting workflow in VSCodium.

Constraints: I need these shares to remain visible and automount (for backups and access in Dolphin); pre-mounting or hiding them isn’t an option.

Workarounds Tried: Various GPU and portal flags, environment variables (GTK_USE_PORTAL=0, ELECTRON_USE_DESKTOP_PORTAL=0), logging, config resets, etc.

Has anyone encountered a similar issue or found a workaround that allows the file dialog to operate normally without triggering the automount (or at least to avoid the delay) while still keeping my NAS shares available? Any advice or suggestions would be greatly appreciated.

Thanks in advance for your help!

—Jack

Mirdarthos · 17 March 2025 07:34

Hi @jackdinn,

This seems like a stoopid question, and maybe it is - I don’t know - but have you tried, just to check, if it happens to something other than VSCodium?

I have several automounts with systemd, both local disks as well as network mounted “shares” and have no such problem.

AFAIK that should be:

GTK_USE_PORTAL=1 codium --disable-gpu

If you haven’t yet, consider trying Code - OSS from the extra repository. It’s basically the same as VSCodium, if I recall correctly, but…I’m not sure if there is a “but” other than that it’s in the repository rather than the AUR. It can be installed with:

pamac install code

linux-aarhus · 17 March 2025 09:59

Then you have other issues … me-think

That is strange conclusion … the automount clearly doesn’t work - otherwise your smb share would mount if the system act as you describe … looks very much like dysfunctional configuration

jackdinn · 17 March 2025 11:12

i tried both GTK_USE_PORTAL=0 & 1, neither made a difference.

I tried nextloud-talk desktop app, i already use it so its easy to check, i looked through the settings to find a file chooser and yes there is also a problem with the file browser (even though that is built into the app) which i had never noticed before as i never needed to use the file picker function on it before. It does not hang at all but it does look like this.

Na, that NAS is the weekly replication of all the other servers, it only boots up once a week. But i do want access to it when i do switch it on for obvious reasons.

I shall take a look, thx.

so whats up with electron what should i do about it??

EDIT:-

well i tried extra/code - oss but its exactly the same problem. The open file dialogue is fine, it opens without problem but the open folder just does not work, its still trying to open a smb mount that is not even accessible at the moment as that NAS is off.

Was worth a try though ,

linux-aarhus · 17 March 2025 12:34

That is why you have this issue - while you certainly can define automounts on remote shares - for as long as you don’t access them - there is no problem.

The only way around that is to create a script to enable/disable your auomount units when they are required.

E.g.

#!/usr/bin/env bash

action=$1

if [[ -z ${action} ]]; then
   echo "provide the action - start / stop as single argument"
   exit 1
fi

if [[ ${action} = "start"  ]]; then
    systemctl enable --now <unit>.automount
else
    systemctl disable --now <unit>.automount
fi

Possibly you can add this to the script executing your backup

I am tempted to define this as an xy-problem - you are trying to fix code file dialog when it is your mount that need adjustment.

jackdinn · 17 March 2025 12:44

so basically your saying i have to disable the mounts (all of them) while electron apps are running?

That’s a not a great solution. I have a couple of background electron apps that I need running permanently, like Nextcloud Talk. If I have to disable all the mounts from the NAS’s that are not on all the time, then I’m basically just disabling them permanently.

my mounts need adjustment? how so?

They work fine, they automount when they are needed. I’m not sure what else you might be referring to.

linux-aarhus · 17 March 2025 12:45

The mount definitions pointing to the NAS which you

Those definitions is creating the problem(s) you see in code - which is why you need to disable those until you actually power up that NAS for your backup procedure.

If you must have automount units enabled - pointing to a service that is only started once a week - I suggest you lower the TimeoutSec in the actual mount unit - e.g. 5s or 10s - depending on how fast your NAS is to respond - when it is actually powered up.

jackdinn · 17 March 2025 13:01

well thats a right pita, i thought that was the point is getting all the mounts to work via automount systemd instead of fstab, it works fine, it mounts them only when i need them, its what they are supposed to do?

Im not trying to access them, why is the electron file browser having trouble but all the other file browsers that iv looked at are fine.

i dont see what the timout has to do with anything, they are not mounted to begin with so the timeout is irreverent as they should not even be trying to mount them.

all the other mounts, the ones that do exist are not being actually mounted by the opening of this file picker. I mean there are a lot of other automounnts that are available and could be auto mounted if thats what the file picker is trying to do but it does not, well not on any of the others only seems to attempt to do it to that one.

❱sudo systemctl list-automounts 
[sudo] password for greg: 
WHAT                             WHERE                          MOUNTED IDLE TIMEOUT UNIT                                   
//192.168.1.117/cavern           /mnt/TRUENASSCALE_cavern       no      5min         mnt-TRUENASSCALE_cavern.automount
//192.168.1.117/home             /mnt/TRUENASSCALE_home         no      5min         mnt-TRUENASSCALE_home.automount
//192.168.1.117/mandie-home      /mnt/TRUENASSCALE_mandie       no      5min         mnt-TRUENASSCALE_mandie.automount
//192.168.1.117/manjaro-home     /mnt/TRUENASSCALE_manjaro_home no      5min         mnt-TRUENASSCALE_manjaro_home.automount
//192.168.1.117/media            /mnt/TRUENASSCALE_media        no      5min         mnt-TRUENASSCALE_media.automount
//192.168.1.100/cavern           /mnt/TRUENAS_cavern            no      30s          mnt-TRUENAS_cavern.automount
//192.168.1.100/home             /mnt/TRUENAS_home              no      30s          mnt-TRUENAS_home.automount
//192.168.1.100/mandie           /mnt/TRUENAS_mandie            no      30s          mnt-TRUENAS_mandie.automount
//192.168.1.100/manjaro-home     /mnt/TRUENAS_manjaro_home      no      30s          mnt-TRUENAS_manjaro_home.automount
//192.168.1.100/media            /mnt/TRUENAS_media             no      30s          mnt-TRUENAS_media.automount
//192.168.1.118/Users/greg/Music /mnt/mandie_music_local        no      30s          mnt-mandie_music_local.automount
binfmt_misc                      /proc/sys/fs/binfmt_misc       no      -            proc-sys-fs-binfmt_misc.automount

12 automounts listed.
Pass --all to see loaded but inactive automounts, too.

so half of these are available to mount but it does not mount any of them, it just seems to be interested in that particular one.

linux-aarhus · 17 March 2025 13:09

You need to think like the system to understand the system… and you need to treat it like a system - not a human.

The systemd automount happens when something accesses the path - that in this instance is the code application’s file dialog - that is what they are for.

The system has no way of knowing that the path it is trying to access is not accessible because the server is offline.

I am guessing that code points the last known location …

The TimeoutSec property in the mount unit - is the time before the system gives up - if none is set it is 90s.

If the server is offline - you are effectively blocked from writing to that path - if you do as I suggest - disable the automount unit - but that would allow you to write to the folder and when you mount it next time you cannot see what is in the local folder because it is hidden by the mount.

So you are right - disabling the automount would likely be a bad idea.

That is why I suggest the TimeoutSec in the mount unit - shorten the time the system waits for the share to come online - to e.g. 5 sec.

Tthis will not prevent the system from trying to access the path but it will shorten the time where the system hangs waiting for something to come online - which it won’t because the server is offline.

I just checked with code - it remembers the last path …

jackdinn · 17 March 2025 13:18

ok well,

❱sudo systemctl disable mnt-TRUENAS_manjaro_home.automount
Removed '/etc/systemd/system/multi-user.target.wants/mnt-TRUENAS_manjaro_home.automount'.

try vscodium, still fails. so lets look in the journel

Defined-By: systemd
░░ Support: https://forum.manjaro.org/c/support
░░ 
░░ A start job for unit mnt-TRUENAS_manjaro_home.mount has finished with a failure.
░░ 
░░ The job identifier is 44395 and the job result is failed.
Mar 17 13:13:16 greg-venusseries xdg-desktop-portal-kde[600771]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkRequested(QString)
Mar 17 13:13:16 greg-venusseries xdg-desktop-portal-kde[600771]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkDone(Solid::ErrorType, QVariant, QString)
Mar 17 13:13:16 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)
Mar 17 13:13:16 greg-venusseries systemd[1]: Mounting Mount SMB Share - manjaro_home Mount...
░░ Subject: A start job for unit mnt-TRUENAS_manjaro_home.mount has begun execution
Mar 17 13:13:41 greg-venusseries mount[637711]: mount error(113): could not connect to 192.168.1.100Unable to find suitable address.
Mar 17 13:13:41 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 17 13:13:41 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 17 13:13:41 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Mount process exited, code=exited, status=32/n/a

❱sudo systemctl status mnt-TRUENAS_manjaro_home.automount
● mnt-TRUENAS_manjaro_home.automount - Automount SMB Share - TRUENAS Manjaro Home
     Loaded: loaded (/etc/systemd/system/mnt-TRUENAS_manjaro_home.automount; disabled; preset: disabled)
     Active: active (waiting) since Sat 2025-03-15 11:04:59 GMT; 2 days ago
 Invocation: 0f4ff8f0a5604d919c23116c7a83e01c
   Triggers: ● mnt-TRUENAS_manjaro_home.mount
      Where: /mnt/TRUENAS_manjaro_home

Mar 17 11:47:35 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)
Mar 17 11:47:42 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)
Mar 17 13:12:53 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)
Mar 17 13:12:58 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)
Mar 17 13:13:04 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)
Mar 17 13:13:10 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)
Mar 17 13:13:16 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)
Mar 17 13:13:23 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)
Mar 17 13:13:29 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)
Mar 17 13:13:35 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.automount: Got automount request for /mnt/TRUENAS_manjaro_home, triggered by 600771 (xdg-desktop-por)

hmm, still trying to open it even after having disabled it and it still does not care about the others.

Last path? but iv not been in that path with this app ever. and i certainly have not been anywhere near if for weeks anywhere else?

linux-aarhus · 17 March 2025 13:39

Perhaps unrelated - what is the benefit of using vscodium instead of code - even visual-studio-code-bin ?

Which xdg-desktop-portal package is installed - preferably xdg-desktop-portal-kde ?

Is it the file chooser based on qt or gtk ?

jackdinn · 17 March 2025 13:48

❱yay -Qs xdg-desktop-portal
local/xdg-desktop-portal 1.20.0-1
Desktop integration portals for sandboxed apps
local/xdg-desktop-portal-kde 6.3.2-1 (plasma)
A backend implementation for xdg-desktop-portal using Qt/KF5

I have tried code -occ it does the same thing.

I have not tried the main vscode as i use linux for a reason and that is mainly the privacy. I shall try it though. Im just testing with the timeout in the .mount , shall see what happens…

Nop still the same with a timeout of 10 secs

I doo see these 2 journel logs every time though as well as the mount stuff, i was wondering what they are.

Mar 17 13:44:59 greg-venusseries xdg-desktop-portal-kde[600771]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkRequested(QString)
Mar 17 13:44:59 greg-venusseries xdg-desktop-portal-kde[600771]: qt.core.qobject.connect: QObject::connect: No such signal Solid::Backends::Fstab::FstabStorageAccess::checkDone(Solid::ErrorType, QVariant, QString)

im on x11 kde,

the file picker… err i can never tell ^^ have a pic.

there is them 2 errors again

Mar 17 13:48:19 greg-venusseries kwin_x11[600684]: kwin_core: XCB error: 152 (BadDamage), sequence: 53129, resource id: 21232087, major code: 143 (DAMAGE), minor code: 2 (Destroy)
Mar 17 13:48:19 greg-venusseries kwin_x11[600684]: kwin_core: XCB error: 3 (BadWindow), sequence: 53130, resource id: 56623435, major code: 129 (SHAPE), minor code: 6 (Input)

Oh sorry, thought they were the same 2 faults but they are not. Just looked the same in the logs. Shall leave them there anyhow.

linux-aarhus · 17 March 2025 14:05

It is not your mount / automount definitions causing problems - they are just manifestation of something else.

I think your problem is theme related - perhaps bookmarks.

The default Open Folder dialog does not contain bookmarks - only the file manager - so something is customized - and that customization trigger the unwanted behavior.

Screenshot

jackdinn · 17 March 2025 14:19

bookmarks??

i cant see any sections that i have that you dont. Places, Remote, Recent, Devices & removable devices. Same as me.

EDIT:

ok i have disabled the automount for TRUENAS_manjaro_home.mount and i have removed it from dolphin. It does not exist any more!

But its still spamming that mount with these.

❱journalctl -p4 -b
Mar 17 14:56:51 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 17 14:56:51 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.
Mar 17 14:56:57 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 17 14:56:57 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 17 14:56:57 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 17 14:56:57 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.
Mar 17 14:57:04 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 17 14:57:04 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 17 14:57:04 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 17 14:57:04 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.
Mar 17 14:57:10 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 17 14:57:10 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 17 14:57:10 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 17 14:57:10 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.
Mar 17 14:57:16 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 17 14:57:16 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 17 14:57:16 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 17 14:57:16 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.
Mar 17 14:57:22 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 17 14:57:22 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 17 14:57:22 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 17 14:57:22 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.
Mar 17 14:57:28 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 17 14:57:28 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 17 14:57:28 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 17 14:57:28 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.
Mar 17 14:57:35 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 17 14:57:35 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 17 14:57:35 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 17 14:57:35 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.
Mar 17 14:59:17 greg-venusseries kwin_x11[600684]: kwin_core: XCB error: 152 (BadDamage), sequence: 37150, resource id: 21332644, major code: 143 (DAMAGE), minor code: 2 (Destroy)
Mar 17 14:59:17 greg-venusseries kwin_x11[600684]: kwin_core: XCB error: 3 (BadWindow), sequence: 37151, resource id: 56623519, major code: 129 (SHAPE), minor code: 6 (Input)
Mar 17 14:59:20 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 17 14:59:20 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 17 14:59:20 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 17 14:59:20 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.

I dont have anything in fstab regarding these mounts. It’s all disabled in systemd now and its removed from Dolphin.

linux-aarhus · 18 March 2025 09:31

You have a lot in Places section - which I don’t - I am referring to those as bookmarks - perhaps they are not but I cannot know - I suspect these folders to be your issue …

The open folder dialog reads the folders - thus initiating a connection request - which will fail because your device is offline

Screenshot snip

jackdinn · 18 March 2025 09:46

Yea sure, I get ya, but why just that one NAS mount? I’ve even removed that one from Dolphin, I’ve disabled it in systemd but it still has loads of journal logs about it trying to mount/open it. None of the other, just that one.

Take a look at my last screen shot the TRUENAS_manjaro_home is not there any more.

So I hide all of “Places” in Dolphin, but it’s still giving the same problem, but it has no NAS mounts referenced on the UI at all now.

Mar 18 09:56:51 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 18 09:56:51 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 18 09:56:51 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 18 09:56:51 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.
Mar 18 09:56:58 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 18 09:56:58 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 18 09:56:58 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 18 09:56:58 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.
Mar 18 09:57:04 greg-venusseries kernel: CIFS: VFS: Error connecting to socket. Aborting operation.
Mar 18 09:57:04 greg-venusseries kernel: CIFS: VFS: cifs_mount failed w/return code = -113
Mar 18 09:57:04 greg-venusseries systemd[1]: mnt-TRUENAS_manjaro_home.mount: Failed with result 'exit-code'.
Mar 18 09:57:04 greg-venusseries systemd[1]: Failed to mount Mount SMB Share - manjaro_home Mount.

Aragorn · 18 March 2025 10:04

You are correct, and that is the OP’s problem. It is trying to read an unmounted remote filesystem because of the bookmarks.

jackdinn · 18 March 2025 10:07

I’v removed the “bookmarks”, I have removed the entire “Places” section, none of them are even shown in the VScode folder picker now. But it still attempts to access the same nas path on the same nas mount.

linux-aarhus · 18 March 2025 11:18

It is somewhere in your configuration… xy on xy on xy

We cannot possibly know what causes this on your system.

Aragorn · 18 March 2025 11:52

Removing the section doesn’t make any difference. It’s the items within that section that cause the problem.