Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Projects containing read-only files cannot be built #1071

Closed
1 task done
acaloiaro opened this issue Feb 22, 2024 · 5 comments · Fixed by #1155
Closed
1 task done

Projects containing read-only files cannot be built #1071

acaloiaro opened this issue Feb 22, 2024 · 5 comments · Fixed by #1155
Labels
bug Something isn't working

Comments

@acaloiaro
Copy link

acaloiaro commented Feb 22, 2024

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

When projects being built by nixpacks contain read-only files, nipacks build ... results in a permission error due to Rust's fs::copy retaining file permissions, and nixpacks rewriting all CRLF line endings with LF:

fs::write(&to, data.replace("\r\n", "\n"))?;

To reproduce

In any project to be built by nixpacks, on a Linux system

touch test
chmod 444 test
nixpacks build .

╔══════ Nixpacks v1.20.0 ══════╗
║ setup      │ go_1_19         ║
║──────────────────────────────║
║ install    │ go mod download ║
║──────────────────────────────║
║ build      │ go build -o out ║
║──────────────────────────────║
║ start      │ ./out           ║
╚══════════════════════════════╝

Error: Writing app

Caused by:
    Permission denied (os error 13)

Here from the strace output, we can see that the permission error occurs opening test as writable

openat(AT_FDCWD, "/run/user/1000/nixpacks.k4jRGy09qM0S/test", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)

And stat shows us that that file retained its original read-only permissions, preventing the writable file handle

stat -c "%a %n" /run/user/1000/nixpacks.k4jRGy09qM0S/test
444 /run/user/1000/nixpacks.k4jRGy09qM0S/test

Expected behavior

  • Nixpacks builds successfully as long as it can read files from project directories
  • That nixpacks does not replace all CRLF with LF in project files.

Environment

OS: NixOS Unstable
Kernel: Linux version 6.6.17 (nixbld@localhost) (gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.40) #1-NixOS SMP PREEMPT_DYNAMIC Fri Feb 16 18:10:57 UTC 2024
Nixpacks version: 1.20.0 / any

@acaloiaro acaloiaro added the bug Something isn't working label Feb 22, 2024
@acaloiaro
Copy link
Author

This may be related to some instances of #700

@vinerz
Copy link

vinerz commented Jun 24, 2024

Having the exact same issue with node provider. The node_modules folder must be removed in order to nixpacks build to succeed. sudo nixpacks works, but I don’t feel comfortable doing that. Even when the build is running as root, the absolute slowness when trying to copy the entire modules directory to the build context almost halts the entire process. Any way we can ignore files like honouring the .gitignore or even a .nixpacksignore?

@acaloiaro
Copy link
Author

I should add if you're having this permission problem and you're okay with setting all permissions within a particular directory to read/write, the following will fix permissions, e.g. ./node_modules: find ./node_modules -perm 444 -exec chmod 0600 {} \

@vinerz
Copy link

vinerz commented Jun 25, 2024

@acaloiaro is there a way for this directory to not be copied at all?

@iloveitaly
Copy link
Contributor

Struggling with this as well:

/usr/bin/find . -path ./.git -prune -o -type f -perm +444 \! -perm +222

This identifies all of the read only files. I confirmed they are all in dockerignore but nixpacks is still failing...

iloveitaly added a commit to iloveitaly/nixpacks that referenced this issue Aug 5, 2024
iloveitaly added a commit to iloveitaly/nixpacks that referenced this issue Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants