Access to host files in Linux

[shurick81]

When I run this container in Linux, it throws error when trying to write to user hiles on the host, so I cannot also use spfx framework. However the same operation works in node:10.18.1 container:

aleks@vm-dev:~/projects/01$ sudo docker run -it --rm --name spfx-helloworld -v $(pwd):/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 waldekm/spfx /bin/bash -c "mkdir 17"
mkdir: cannot create directory '17': Permission denied
aleks@vm-dev:~/projects/01$ sudo docker run -it --rm --name spfx-helloworld -v $(pwd):/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 node:10.18.1 /bin/bash -c "mkdir /usr/app/spfx/18"
aleks@vm-dev:~/projects/01$ ls
13  15  16  18

Might it have something to do with the way we setup permissions in waldekm/spfx?

Linux machine is provisioned in Azure, from this image:

    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-focal"
    sku       = "20_04-lts-gen2"
    version   = "20.04.202007290"

[waldekmastykarz]

I see that in the first case you're using just the folder name, whereas in the other case you use the full path. Could it be that you're trying to create the folder in a folder where you don't have the access to?

[shurick81]

Hi, I used folder name because in spfx container we already have workdir altered: https://github.com/waldekmastykarz/docker-spfx/blob/master/Dockerfile#L8.

Here's a cleaner test:

aleks@vm-dev:~/projects/00$ sudo docker run -it --rm --name spfx-helloworld -v $(pwd):/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 -w /usr/app/spfx node:10.18.1 /bin/bash -c "mkdir 18"
aleks@vm-dev:~/projects/00$ sudo docker run -it --rm --name spfx-helloworld -v $(pwd):/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 -w /usr/app/spfx waldekm/spfx:1.11.0 /bin/bash -c "mkdir 17"
mkdir: cannot create directory '17': Permission denied
aleks@vm-dev:~/projects/00$ ls
18

So yes, it could be some issues with permissions. Since it only appears in linux, I can draw a conclusion that it is related to permissions on the host directory.

[waldekmastykarz]

Is there a particular reason why you're trying to create the folder as the starting command in the container?

[shurick81]

yes, this is just a simple test that I came up with while investigated why creating a solution did not work in docker when I run it on Linux VM:

aleks@vm-dev:~/projects/00$ sudo docker run -it --rm --name spfx-helloworld -v $(pwd):/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 waldekm/spfx:1.11.0 yo @microsoft/sharepoint --solution-name docker-spfx-test02 --component-type webpart --component-name wello-world-webpart --component-description "HelloWorld web part" --is-domain-isolated --framework none --environment spo --skip-feature-deployment false
? ==========================================================================
We're constantly looking for ways to make yo better! 
May we anonymously report usage statistics to improve the tool over time? 
More info: https://github.com/yeoman/insight & http://yeoman.io
========================================================================== Yes

     _-----_
    |       |    .--------------------------.
    |--(o)--|    |      Welcome to the      |
   `---------´   |  SharePoint Client-side  |
    ( _´U`_ )    |    Solution Generator    |
    /___A___\    '--------------------------'
     |  ~  |     
   __'.___.'__   
 ´   `  |° ´ Y ` 

A folder with solution name docker-spfx-test02 will be created for you.
A component for the spo environment will be created for you.
A web part with the name wello-world-webpart will be added to your solution.
Web part description is going to be HelloWorld web part.
Let's create a new SharePoint solution.
Found npm version 6.14.6

Error: EACCES: permission denied, mkdir '/usr/app/spfx/docker-spfx-test02'

Same command in Docker Desktop works fine.

[shurick81]

This might be also relevant.

Docker Desktop:

PS C:\projects\00> docker run -it --rm -v ${pwd}:/usr/app/spfx -w /usr/app/spfx waldekm/spfx:1.11.0 /bin/bash -c "ls -ld"
drwxrwxrwx 1 root root 4096 Aug 21 04:04 .
PS C:\projects\00> docker run -it --rm -v ${pwd}:/usr/app/spfx -w /usr/app/spfx node:10.18.1 /bin/bash -c "ls -ld"
drwxrwxrwx 1 root root 4096 Aug 21 04:04 .

Docker Engine, docker-ce for Linux:

aleks@vm-dev:~/projects/00$ sudo docker run -it --rm -v $(pwd):/usr/app/spfx -w /usr/app/spfx waldekm/spfx:1.11.0 /bin/bash -c "ls -ld"
drwxrwxr-x 2 node node 4096 Aug 22 16:15 .
aleks@vm-dev:~/projects/00$ sudo docker run -it --rm -v $(pwd):/usr/app/spfx -w /usr/app/spfx node:10.18.1 /bin/bash -c "ls -ld"
drwxrwxr-x 2 node node 4096 Aug 22 16:15 .

[shurick81]

I have tested this approach with Windows and Linux hosts and it worked just fine for creating solutions: shurick81@4d5dcf9. Or should we look maybe why the permissions in Linux don't work when using "spfx" user?

[waldekmastykarz]

When you execute the ls commands, what's the working folder? Could it be that the current user doesn't have permissions to access it?

[mzietlow]

Not sure if this is related or useful to anyone, but to run under Linux, I had to:
1.) Find the UID of the spfx user (1001 in the following)
2.) Create a folder for the deployment (deployment in the following)
3.) Inside ./deployment create a file (npm-shrinkwrap.json) according to https://stackoverflow.com/a/60921145
4.) run sudu chown -R 1001:1001 ./deployment
5.) cd ./deployment
6.) docker run -it --rm --name ${PWD##*/} -v $PWD:/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 waldekm/spfx
7.) yo @microsoft/sharepoint and follow the setup
8.) Open a new console and run sudo vim ./deployment/config/serve.json
8.1) set the https entry to false
8.2) remove the s from https in the initialPage entry

I was unable to deploy with SSL, but that wasn't a requirement for my small demo anyways

[shurick81]

Hi, thanks for your experience @mzietlow! I can share my experience with using WSL2 in Windows. I did not have to create the npm-shrinkwrap.json file. What I had to do is only running this command in the project directory in WSL2 console:

sudu chown -R 1001:1001 .

[shurick81]

I think we should conclude this behavior by design since when we mount a linux file system to a linux container, and the process in the container is working under 1001 identity, this identity should have appropriate permissions on the host file system.