How to keep brwap from crashing with unreliable NFS mount?

Help
1

My system has a NFS mount to a server that is currently down for maintenance. That should be fine, and when it comes back the system should automatically mount it at that point as I understand the configuration below. My problem is that vscode.fhs is now failing to run with

bwrap: Can't bind mount /oldroot/mnt on /newroot/mnt: Unable to apply mount flags: remount "/newroot/mnt/synomedia": No such device

I am assuming this is a side effect from using the fhs version of vscode and the integration with bwrap trying to blindly wrap the NFS mount points even if they are not connected. The NFS mount configuration options…

services.rpcbind.enable = true; # needed for NFS
  systemd.mounts = let commonMountOptions = {
    type = "nfs";
    mountConfig = {
      Options = "noatime";
    };
  };
  in
  [
    (commonMountOptions // {
      what = "10.0.0.1:/volume1/video";
      where = "/mnt/synomedia";
    })
  ];

  systemd.automounts = let commonAutoMountOptions = {
    wantedBy = [ "multi-user.target" ];
  };
  in
  [
    (commonAutoMountOptions // { where = "/mnt/synomedia"; })
  ];

Seems that a random unconnected Mount should not prevent vscode from running :wink: While I can probably comment out the NFS mount point for now and rebuild my configuration… that seems like a undesirable type of workaround. I would expect the bwrap to simply ignore the unconnect NFS mount point. Thoughts? Other work arounds?

2

I don’t use VSCode, but a possible workaround for the bwrap issue would be to create a bindmount the remounts the NFS dir to a new location, and then point your VSCode FHS at that.

Since the bindmount should always exist (but will be empty if the NFS is offline), this should work.