SSH: Error when running existing tasks in workspace on Windows host: "Unable to write to Folder Settings because no resource is provided"

[jonchancode]

Issue Type: Bug

Brief

When I use VSCode to ssh (Windows client) into a workspace on a Windows host with existing tasks, and then try to run them, I get an error.

Reproduce

1. On Windows host, create a VSCode workspace and add a simple default task, "foo" (e.g. echo hello).
2. On Windows client, use VSCode to ssh into the host and open the existing workspace. Use the same user/credentials to log on.
3. Attempt to run the existing "foo" task. VSCode will first complain that no tasks yet exist, and then when you try to configure a new one, it will fail with Unable to write to Folder Settings because no resource is provided

VS Code version: Code 1.57.1 (507ce72a4466fbb27b715c3722558bb15afa9f48, 2021-06-17T13:28:07.755Z) OS version: Windows_NT x64 10.0.19042 Restricted Mode: No Remote OS version: Windows_NT x64 10.0.19043

My theory

I think it's a permissions issue. Looking at the logs, there seems to be an exception when opening the .vscode files:

[2021-06-18 12:13:03.716] [renderer1] [error] Unable to write to Folder Settings because no resource is provided.: Error: Unable to write to Folder Settings because no resource is provided.
    at v.reject (file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2409:15315)
    at v.resolveAndValidate (file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2409:18857)
    at v.doWriteConfiguration (file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2409:12505)
    at Object.factory (file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2409:12281)
    at E.consume (file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:68:16017)
    at file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:68:15832
    at new Promise (<anonymous>)
    at E.queue (file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:68:15756)
    at v.writeConfiguration (file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2409:12266)
    at E.writeConfigurationValue (file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2409:41473)
    at file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2409:27566
    at Array.map (<anonymous>)
    at E.updateValue (file:///C:/Users/jonch/AppData/Local/Programs/Microsoft VS Code/resources/app/out/vs/workbench/workbench.desktop.main.js:2409:27554)

So I created another workspace via the ssh session on the host, and created some tasks there, and everything works as expected. When looking at the owner of the tasks.json in the new workspace, I noticed that the owner is the machine's Administrators group, whereas the owner of the existing tasks.json (with "foo" task) is just an ordinary user (no mention of administrator). When I change the owner of the tasks.json in the new workspace to the ordinary user, I get the same error again.

Note, the user I used to create the existing workspace and to log on is the same user, and is an administrator on the machine.

My suspicion is that VSCode ssh is executing everything with the admin access token, instead of the unelevated access token, which the local VSCode uses by default?

Humble suggestions assuming it's permissions related

If VSCode is running with the admin token, shouldn't it still be able to interact with existing .vscode files? I seem to be able to modify and save existing files on the system - it's just VSCode internally throwing an exception when trying to write its own files.

Furthermore, perhaps VSCode ssh should actually be executing things with the unelevated access token, and prompt user if admin access is necessary? This seems much safer and more aligned with general UAC principles.

I'm a novice at permissions architecture, just some thoughts :).

Edits

The initial bug report showed "Restricted Mode: Yes". I don't think that's the case... I was messing around with the host existing work space by changing the folder owner, and then when I re-opened the workspace on the client, it put me in restricted mode despite me wanting to trust the workspace. I'm quite certain that originally, I was no in restricted mode.

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz (12 x 1608)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|15.79GB (7.97GB free)| |Process Argv|--crash-reporter-id 5ecd9a28-05f0-498c-9591-1639b91a2ce1| |Screen Reader|no| |VM|0%| |Item|Value| |---|---| |Remote|SSH: jonchan-desk4| |OS|Windows_NT x64 10.0.19043| |CPUs|Intel(R) Core(TM) i9-7920X CPU @ 2.90GHz (24 x 2904)| |Memory (System)|63.80GB (30.24GB free)| |VM|0%|

Extensions (5)

Extension|Author (truncated)|Version ---|---|--- Bookmarks|ale|13.1.0 remote-ssh|ms-|0.65.7 remote-ssh-edit|ms-|0.65.7 remote-wsl|ms-|0.56.5 ninja|sur|0.0.1

A/B Experiments

``` vsliv368cf:30146710 vsreu685:30147344 python383:30185418 pythonvspyt602:30300191 vspor879:30202332 vspor708:30202333 vspor363:30204092 vswsl492cf:30256860 pythonvspyt639:30300192 pythontb:30283811 vspre833:30321513 pythonptprofiler:30281270 vshan820:30294714 vscoreces:30322571 pythondataviewer:30285071 vscus158:30321503 pythonvsuse255:30323308 vscorehov:30309549 vscod805cf:30301675 binariesv615:30323119 vsccppwt:30322536 ```

[roblourens]

I can't repro this. Are you sure you are logging in with the exact same credentials?

When looking at the owner of the tasks.json in the new workspace, I noticed that the owner is the machine's Administrators group, whereas the owner of the existing tasks.json (with "foo" task) is just an ordinary user (no mention of administrator).

Where do you see that?

Any idea about this error message @sandy081?

[sandy081]

Unable to write to Folder Settings because no resource is provided.: Error: Unable to write to Folder Settings because no resource is provide

It means that, extension is trying to write a setting into workspace folder target in a multi root workspace without providing the resource.

[roblourens]

Ok. I think the error message is not related to the task issue then.

[jonchancode]

Thanks for taking a look. I am actually also having trouble reproducing the issue again. I'll close the issue. Sorry for the distraction!