Windows WSL2: Operation not permitted on old project

[Tinathnath]

Hi !
I'm trying to run an old project (1.5.1) with Docker on Windows 11 + WSL 2 (Ubuntu).
Container starts fine but I'm unable to gulp serve or gulp bundle, I always get EPERM operation not permitted error and I can't get it to work. Maybe it's related to #65
Here is the error I get:

My configuration: Windows 11 + WSL 2 on Ubuntu. My project is located on an external drive mounted in WSL.
I ran the container with this command: docker run -it --rm --name spfx1.5.1 -v ${PWD}:/usr/app/spfx -p 4321:4321 -p 35729:35729 m365pnp/spfx:1.5.1

I tried configuring WSL with this wsl.conf file

[automount]
enabled = true
options = "metadata"
mountFsTab = false

Am I missing something obvious here ?
Thank's for the reply

[shurick81]

Looks like a typical permissions issue in Linux/Docker.

Here's how I usually deal with existing projects in WSL2:

1. git clone
2. sudo chown -R 1001:1001 .
3. docker run --rm -it -v $(pwd):/usr/app/spfx -p 4321:4321 -p 35729:35729 m365pnp/spfx
4. run in the container:

npm install
chmod -R u=rwx,g=rx,o=rwx .
gulp trust-dev-cert
gulp serve --nobrowser

5. Run on the host for trusting the certificate:

$tcpClient = New-Object -TypeName System.Net.Sockets.TcpClient;
$tcpClient.Connect("localhost", 4321);
$tcpStream = $tcpClient.GetStream();
$callback = { param($sender, $cert, $chain, $errors) return $true };
$sslStream = New-Object -TypeName System.Net.Security.SslStream -ArgumentList @($tcpStream, $true, $callback);
$sslStream.AuthenticateAsClient('');
$certificate = $SslStream.RemoteCertificate;
$x509Certificate = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList $certificate
$store = new-object System.Security.Cryptography.X509Certificates.X509Store(
    [System.Security.Cryptography.X509Certificates.StoreName]::Root,
    "currentuser"
)
$store.open("MaxAllowed");
$store.add($x509Certificate);
$store.close();

By the way, I think for the old SPFx you will also need 5432 port.

[Tinathnath]

Hi, thanks for the reply !

I don't have permissions issues anymore so I guess you were right :) I used to run the container from the host, not from WSL.

gulp serve starts but it's very slow (3 min to start !) and I can't call it from the host...
Chrome says "connection reset" and the PowerShell to trust the cert fails with error "Received an unexpected EOF or 0 bytes from the transport stream." when trying to authenticate the stream.

I binded the 3 ports, I don't see the issue here

[shurick81]

Here's the test I run

cd spfx-test-02
sudo chown 1001:1001 .
docker run --rm -v $(pwd):/usr/app/spfx m365pnp/spfx:1.5.1 yo @microsoft/sharepoint --solution-name helloworld --component-type webpart --component-name hello-world-webpart --component-description "HelloWorld web part" --is-domain-isolated --framework none --environment spo --skip-feature-deployment false --skip-install

replace "skipFeatureDeployment": "false" with "skipFeatureDeployment": false

modify config\write-manifests.json to (add the debugBasePath property):

{
  "$schema": "https://developer.microsoft.com/json-schemas/spfx-build/write-manifests.schema.json",
  "cdnBasePath": "<!-- PATH TO CDN -->",
  "debugBasePath": "https://localhost:4321/"
}

cd helloworld
docker run --rm -it -v $(pwd):/usr/app/spfx -p 4321:4321 -p 5432:5432 -p 35729:35729 m365pnp/spfx:1.5.1

npm install
chmod -R u=rwx,g=rx,o=rwx .

open node_modules\@microsoft\sp-build-web\lib\SPWebBuildRig.js and change lines 78-81 from:

        spBuildCoreTasks.writeManifests.mergeConfig({
            deployCdnPath: spBuildCoreTasks.copyAssets.taskConfig.deployCdnPath,
            debugBasePath: `${serve.taskConfig.https ? 'https' : 'http'}://${serve.taskConfig.hostname}:${serve.taskConfig.port}/`
        });

to (add the if statement):

if (!spBuildCoreTasks.writeManifests.taskConfig.debugBasePath) {
        spBuildCoreTasks.writeManifests.mergeConfig({
            deployCdnPath: spBuildCoreTasks.copyAssets.taskConfig.deployCdnPath,
            debugBasePath: `${serve.taskConfig.https ? 'https' : 'http'}://${serve.taskConfig.hostname}:${serve.taskConfig.port}/`
        });
}

gulp trust-dev-cert
gulp serve --nobrowser

$tcpClient = New-Object -TypeName System.Net.Sockets.TcpClient;
$tcpClient.Connect("localhost", 5432);
$tcpStream = $tcpClient.GetStream();
$callback = { param($sender, $cert, $chain, $errors) return $true };
$sslStream = New-Object -TypeName System.Net.Security.SslStream -ArgumentList @($tcpStream, $true, $callback);
$sslStream.AuthenticateAsClient('');
$certificate = $SslStream.RemoteCertificate;
$x509Certificate = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList $certificate
$store = new-object System.Security.Cryptography.X509Certificates.X509Store(
    [System.Security.Cryptography.X509Certificates.StoreName]::Root,
    "currentuser"
)
$store.open("MaxAllowed");
$store.add($x509Certificate);
$store.close();

Mind you @Tinathnath that I used port 5432 for the script that is reading the certificate. Could you try that also?

[Tinathnath]

Hi @shurick81
Sorry for the late reply, I was away :)

I tried your solution. After chmod 1001:1001 the container does not start:

docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "[B": executable file not found in $PATH: unknown.
ERRO[0000] error waiting for container: context canceled

I also tried the solution in the official docs (I missed it the first time):

It works, I can access the server from my host and load it in a SharePoint page. However I'm still not able to save files from VS Code... I think I need a certain chmod tu be able to save, and another to be able to run 😢

Finally, changing code in node_modules so the system can start is not a stable dev environment. I wanted to use Docker to gain time and get a flexible dev environment, but in the end, NVM is way better option. Microsoft is using outdated libraries and regarding the vulnerabilities in the last v1.15 they still don't plan on fixing them...