Npx create-react-app fails with Error: EPERM: operation not permitted, copyfile yarn.lock.cached -> yarn.lock

Hello:

I’m trying to create a new react project using create-react-app:

devilbox@php-7.4.19 in /shared/httpd/storybook-01/htdocs $ npx create-react-app storybook-test-001

Creating a new React app in /shared/httpd/storybook-01/htdocs/storybook-test-001.

node:fs:2797
handleErrorFromBinding(ctx);
^

Error: EPERM: operation not permitted, copyfile ‘/home/devilbox/.npm/_npx/c67e74de0542c87c/node_modules/create-react-app/yarn.lock.cached’ → ‘/shared/httpd/storybook-01/htdocs/storybook-test-001/yarn.lock’
at Object.copyFileSync (node:fs:2797:3)
at copyFile (/home/devilbox/.npm/_npx/c67e74de0542c87c/node_modules/fs-extra/lib/copy-sync/copy-sync.js:67:6)
at onFile (/home/devilbox/.npm/_npx/c67e74de0542c87c/node_modules/fs-extra/lib/copy-sync/copy-sync.js:53:25)
at getStats (/home/devilbox/.npm/_npx/c67e74de0542c87c/node_modules/fs-extra/lib/copy-sync/copy-sync.js:48:44)
at startCopy (/home/devilbox/.npm/_npx/c67e74de0542c87c/node_modules/fs-extra/lib/copy-sync/copy-sync.js:38:10)
at handleFilterAndCopy (/home/devilbox/.npm/_npx/c67e74de0542c87c/node_modules/fs-extra/lib/copy-sync/copy-sync.js:33:10)
at Object.copySync (/home/devilbox/.npm/_npx/c67e74de0542c87c/node_modules/fs-extra/lib/copy-sync/copy-sync.js:26:10)
at createApp (/home/devilbox/.npm/_npx/c67e74de0542c87c/node_modules/create-react-app/createReactApp.js:330:10)
at /home/devilbox/.npm/_npx/c67e74de0542c87c/node_modules/create-react-app/createReactApp.js:226:9
at processTicksAndRejections (node:internal/process/task_queues:96:5) {
errno: -1,
syscall: ‘copyfile’,
code: ‘EPERM’,
path: ‘/home/devilbox/.npm/_npx/c67e74de0542c87c/node_modules/create-react-app/yarn.lock.cached’,
dest: ‘/shared/httpd/storybook-01/htdocs/storybook-test-001/yarn.lock’
}

I’ve searched around for the problem, but I’m stuck. The closest thing I’ve found is a problem with spaces in the paths, but as you can see, there are none.

Help?

Thanks!

This reads like a file permission error.

Hi, Cy:

Thanks for replying.

So I just ran the same command again, and this time it worked. The only thing I can think of is that I may have restarted the OS or devilbox in the intervening time. Or maybe I connected to a new shell?

But, your correct of course: it’s a permissions issue. Here’s something odd:

devilbox@php-7.4.19 in /shared/httpd/storybook-01/htdocs $ ll
total 0
drwxrwxrwx 1 root     root     4096 May 27 01:44 ./
drwxrwxrwx 1 root     root     4096 May 23 14:38 ../
drwxr-xr-x 1 devilbox devilbox 4096 May 27 02:03 my-app/
drwxrwxrwx 1 root     root     4096 May 23 15:33 myapp/
drwxrwxrwx 1 root     root     4096 May 23 15:28 storybook-test-001/

The two dirs owned by root/root were the ones that were producing the error. The new one, my-app is the one that worked just now.

I’ve noticed the mix of devilbox and root owners elsewhere:

devilbox@php-7.4.19 in /shared/httpd $ ll
total 4
drwxr-xr-x 1 devilbox devilbox 4096 May 21 13:41 ./
drwxr-xr-x 1 root     root     4096 May 25 01:57 ../
drwxr-xr-x 1 devilbox devilbox 4096 Apr 10 16:55 jetstream-01/
drwxrwxrwx 1 root     root     4096 Mar 29 01:31 laravel-01/
drwxr-xr-x 1 devilbox devilbox 4096 Apr  4 03:28 livewire-test-01/
drwxrwxrwx 1 root     root     4096 Mar 29 01:30 project-1/
drwxrwxrwx 1 root     root     4096 Oct 23  2020 project-2/
drwxrwxrwx 1 root     root     4096 Mar 29 01:31 sillaj-l/
drwxrwxrwx 1 root     root     4096 May 23 14:38 storybook-01/
-rwxrwxrwx 1 root     root        0 Aug 16  2020 .keepme

Which user should own things in devilbox? Is it a problem to have devilbox and root owning things, or should it be one or the other? If so, is a chown enough?

Also, what’s the correct permissions? 777? 755?

Thanks again!

It should be the devilbox user, as this is also the one using the same uid/gid as you do use on your local system. See here for details: https://devilbox.readthedocs.io/en/latest/readings/syncronize-container-permissions.html

It depends :slight_smile:
In general, directories should be 0755 (or 0775) and files should be 0644 (or 0664).

Thanks, Cy.

I’m pretty sure all of my problems were related to my clinging to keeping things on the “Windows side” in Windows 10. Once I saw the light and moved things over the Linux side, everything got much, much better.

Thanks!