strapi import fails: error: [FATAL] EBUSY: resource busy or locked

[exotexot]

Bug report

Required System information

• Node.js version: 16
• NPM version:
• Strapi version: 4.6.0
• Database: postgres
• Operating system: unbuntu/docker

Describe the bug

I really appreciate the new new strapi export / import feature!
yarn strapi export is successful! I get the confirmation overview of my existing db entries.

I recreate another strapi instance, same content types are established.
strapi import crashes:

$ strapi import -f backups/my-strapi-export.tar.gz
? The import will delete all data in your database. Are you sure you want to proceed? Yes
Starting import...
[2023-01-27 18:17:21.936] error: [FATAL] EBUSY: resource busy or locked, rename '/opt/app/public/uploads' -> '/opt/app/public/uploads_backup_1674843441931'
Import process failed.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
/opt/app #

Steps to reproduce the behavior

strapi import

Expected behavior

Successful strapi import

[exotexot]

I'm using strapi in a docker. So in my docker file I moved the public/uploads to a different volumen (which is basically a rename of the original folder) And I end up getting a different error:

error: [FATAL] EXDEV: cross-device link not permitted, rename '/opt/app/public/uploads' -> '/opt/app/public/uploads_backup_1675082288686'

[derrickmehaffy]

confirmed based on a convo with a user on Discord today. I have not reproduced it myself.

[marsicdev]

Same issue here, it looks like that running strapi server in the container is locking the folder, and import script can not use to finish import since it needs to create a copy to complete.

[exotexot]

Does that mean that it will not work with strapi in a docker at all?
I was hoping that #15737 fixes the issue, however it didn't for me. :(

[exotexot]

Actually since strapi 4.6.1 I could get it to work when I actually rename the uploads folder...

[exotexot]

...which is still just a workaround.

[exotexot]

This issue also exists, when I'm using the --only content flag and even --exclude files.

This seems weird that it shows the same error message, as the uploads folder shouldn't be touched in those scenarios..

[jurf]

Happened to me too; I did not manage to workaround it so I did the export/import with pgadmin and the uploads manually.

I did not work even without a mount at ./public/uploads. If the folder was not there, it complained that it wasn’t there; if it was, it complained it could not create it because it already existed.