Hi Guix-Jupyter, Please let me know if this is the right location to file a bug. Since I don't have an account on gitlab.inria.fr, I can't file an issue there.
In any case, the ;;guix download directive assumes the ability to hard link from the gnu store to your tmp directory. This killed the Guix kernel and returned an "Operation not permitted" error in my Jupyter console. As it turns out, there is a kernel parameter called "fs.protected_hardlinks" which prevents the creation of hard links by users that do not own the source. Since my gnu store is root owned and I run Jupyter as non-root (hence creating the container in the tmp directory as non-root), this fails. For my system "fs.protected_hardlinks" was set to 1 by default. Setting it to 0 fixes the problem. However, I am not convinced hard linking is the right solution anyway. For one, it is not uncommon to have tmp and the gnu store living on different volumes (which seems to be fixed upstream, but not tagged yet). Copying would be an improvement, as it circumvents these issues, but with the obvious downside that it duplicates all the data. I was thinking it might make more sense to bind mount the file into the container. This would solve the above issues, but not duplicate the data. The raw data would then be completely immutable, however, I do not see this as a downside, since treating raw data as immutable is already a good practice. WDYT? Best wishes, Troy