Access to external files

[guaraqe]

I am trying to access external files from a bundled executable, and I am getting "File not found" errors. As I understand, the executable is in a virtual file system, so that it is understandable it not finding the files. Is there any solution for this?

Thanks!

[matthewbauer]

Where is the file you need access to? We only map certain directories to the namespace, so this is probably where it comes from:

https://github.com/matthewbauer/nix-bundle/blob/master/nix-user-chroot/main.cpp#L102-L110

Until recently, /home was not mapped. I'm starting to think we should just map everything.

[guaraqe]

The files are under my own home, in the same directory as the generated bundle. Is the behavior I saw expected?

Indeed, it would be nice to have the option of having the file system intact except for the nix store.

[flicaflow]

I'm running into problems when trying to access external files. My application is failing to access anything outside of the bundle even / I simplified it to following expression

{ 
  pkgs ? import <nixpkgs> {}
}:
let
  inherit (pkgs) nix-bundle;
  frontend = pkgs.writeShellScriptBin "runfrontend" ''
    echo Bundle Test
    echo $PWD
    ls
    ls -l /
    ls -l /var
    ls -l /var/log
  '';

  bundle = import "${nix-bundle}/share/nix-bundle" { nixpkgs = pkgs; };
  foo = bundle.nix-bootstrap {
    target = "${frontend}";
    run = "/bin/runfrontend";
  };
in foo

I build the bundle inside a nix expression as seen at #25 This fails miserably:

./result 
Bundle Test
/
/nix/store/zirs3hm7zdvap6b16k0a0smp16ic96ql-runfrontend/bin/runfrontend: line 4: ls: No such file or directory
/nix/store/zirs3hm7zdvap6b16k0a0smp16ic96ql-runfrontend/bin/runfrontend: line 5: ls: No such file or directory
/nix/store/zirs3hm7zdvap6b16k0a0smp16ic96ql-runfrontend/bin/runfrontend: line 6: ls: No such file or directory
/nix/store/zirs3hm7zdvap6b16k0a0smp16ic96ql-runfrontend/bin/runfrontend: line 7: ls: No such file or directory

The real application is not a shell script but fails in a similar way while trying to access the file system. I guess I'm missing something big here?

[flicaflow]

Ok I'm having a hard time pinning the error down. Sorry for making noise here, but I think I should make this straight. The above bundle doesn't work because 'ls' is not bundled. Using Version 0.2.0 my app failed because /var is not available, this is fixed in 0.3.0 as far as I know.

[takeda]

Until recently, /home was not mapped. I'm starting to think we should just map everything.

@matthewbauer is that possible to do? I found this ticket because I used the command to bundle saltstack and am getting that there's no /bin/bash so for me at least /bin and /sbin would be nice. I noticed another PR that /bin apparently is a symlink to /usr/bin but some commands are only in /bin (/bin/bash is one of them).

[tylerjl]

Until recently, /home was not mapped. I'm starting to think we should just map everything.

I'd love for this to happen (I just got done debugging this before tracking my problem down to this issue). I ultimately resolved it by getting my files in via /tmp.

FWIW, if filesystem isolation was a Big Selling Point then I'd hesitate to ask for "map everything", but as it stands this is sort of surprising behavior and changing it to have visibility into the rest of the filesystem would make it behave more like "just another executable". Thanks for tracking this :+1:

[jra]

Is there a way to map everything like:

./nix-bundle.sh --map-everything emacs-nox /bin/emacs

?

Bundling emacs, copying it to a non-Nix system, and running it there is not very useful if it cannot find my ~/.emacs.d/init.el and read/write files on the host/target system generally.

I was able to get a relocatable emacs that finds my init.el and can read/write files on the target/host system with Guix pack and here guix pack --relocatable. I'm not sure how it differs from nix-bundle, except that it creates a tarball that is extracted on the target system, and then I run apps out of it like ./guix-env-3.0/opt/gnu/bin/emacs. I would happily trade the chore of extracting and digging for apps, in exchange for apps that see the target filesystem just like other apps, or at least seem to.