为什么在singularity容器中装载主目录会破坏python导入？

我一直在构建一个singularity容器来运行一些python代码，尽管阅读了singularity文档，但我无法理解错误/行为

首先，容器是从docker引导的Ubuntu18.04，即：

Bootstrap: docker
From: ubuntu:18.04

我需要使用python模块（neuron），它需要事先编译。我在定义文件的

%post

部分编译代码，并添加了环境变量：

echo 'export PATH=$PATH:/usr/local/nrn/x86_64/bin' >>$SINGULARITY_ENVIRONMENT
echo 'export LD_LIBRARY_PATH=/usr/local/nrn/x86_64/lib:$LD_LIBRARY_PATH' >>$SINGULARITY_ENVIRONMENT

我可以构建没有太多问题的容器（使用

sudo singularity build--sandbox

）。但我一直在尝试运行一个测试脚本（test.py），以确保一切按预期进行。在脚本中，我导入有问题的模块（neuron），然后尝试将列表保存到csv，以确保可以正确保存数据。看起来是这样的：

import neuron #this fails and gives an unusual error in specific circumstances I don't understand (described below)
import numpy as np

some_data = [1,2,3]
np.savetxt('test_results.csv',np.asarray(some_data),delimiter=',') 

根据我在使用

singularity exec

时提供的标志，我得到了不同的结果，但我不理解（或者不知道从哪里开始理解-这是神经元、singularity还是

ubuntu

问题？）

为了完整起见，容器（和test.py）位于运行这些命令的同一目录中（在我的示例中为so dir）。因此，如果我挂载$HOME，不使用

--no HOME

标志，并尝试像这样运行test.py：

singularity exec--writeable--bind/home/bidby/path/to/some/dir:/mnt my_container.simg python3/mnt/test.py

我得到这样的错误：<代码> DLOPEN失败- X86Y64／.LIBS/LIBNRNMECH.SO：未定义的符号：Celsis。我尝试过Google公平的一个比特，可能是C++链接错误（但是我只知道Python，所以调试这不容易）。 但是，如果我使用

--no home

标志，即：

singularity exec--no home--writeable--bind/home/bidby/path/to/some/dir:/mnt my_container.simg python3/mnt/test.py

然后模块导入成功，出现新错误：

Traceback (most recent call last):
  File "/mnt/test.py", line 15, in <module>
    np.savetxt('test_results.csv',np.asarray(some_data),delimiter=',')
  File "/usr/local/lib/python3.6/dist-packages/numpy/lib/npyio.py", line 1352, in savetxt
    open(fname, 'wt').close()
PermissionError: [Errno 13] Permission denied: 'test_results.csv'

回溯（最近一次呼叫最后一次）：
文件“/mnt/test.py”，第15行，在
np.savetxt（'test_results.csv'，np.asarray（一些_数据），分隔符='，'））
savetxt中的文件“/usr/local/lib/python3.6/dist-packages/numpy/lib/npyio.py”，第1352行
打开（fname，'wt'）。关闭（）
PermissionError:[Errno 13]权限被拒绝：“test_results.csv”

我已经在谷歌上连续搜索了好几天了，但我不知道问题出在哪里。从我所学和测试的内容来看，我认为这可能与环境变量如何传递到容器中有关，尽管我无法理解为什么我没有在这里保存的权限。但是如果我能理解为什么使用

--no home

标志会影响模块导入，我觉得这可能会得到解决

这可能无助于解决问题，但我注意到/尝试过的其他事情：

如果我使用

--containall

标志，我可以毫无问题地运行test.py，但是我尝试保存的csv文件永远找不到。我检查了文件，上面写着：

使用--containall（或简称-C）标志，$HOME不会装入，并且会在$HOME点创建一个虚拟绑定装入。不能使用-B`（或--bind）绑定$HOME目录，因为它会创建一个空装载。因此，如果您在/home/user的图像中有文件，--containall标志将全部隐藏

我假设这个“虚拟绑定挂载”是文件被写入的地方，因此我永远也找不到它

如果我使用

sudo

和

--writable

标志将shell放入容器中，我可以毫无问题地导入neuron。如果我不使用这两个标志中的任何一个，那么我会从上面得到相同的“undefined symbol”错误

如果我没有导出LD_LIBRARY_路径，那么我会在引用不同的.so文件时遇到不同的dlopen错误，说该文件不存在-这再次证明了我的想法，即这是一个路径问题

我知道我没有包含足够的代码来重现这个错误，因为我猜没有人有时间/精力来构建这个容器（因为它相当大），但我认为我已经包含了最相关的部分。如果需要，我们将很乐意添加更多

---

调试这对我来说是一场噩梦，如果有人能为我指明谷歌搜索的正确方向，我将非常感激。

这当然看起来像是一个环境问题，但远程调试比本地调试更困难。有一件事很有帮助：使用

--clean env

选项以及

--no home

。这将使容器环境独立于主机环境。这可能会解决你的问题，或者至少指向一个新的问题

接下来显示的写入错误来自您的测试脚本，您使用的是您正在写入的文件的相对路径。一般来说，这意味着它将被写入执行脚本的目录。您是否具有该目录的写入权限，或者是否存在具有该名称但您没有写入权限的现有文件

---

可能不相关，但是：你使用的是什么版本的奇点

.simg

用于2.x文档，而

.sif

通常用于3.x文档。如果您仍然使用2.x，我强烈建议您更新到最新的3.x版本。2.x不再在上开发，并且大多数<2.6.1的版本都存在安全问题。如果您的集群管理员更新缓慢，指出这一点可以帮助激发他们的积极性。

Ahh，我将目录更改为

mnt/test\u results.csv

，这很好，现在（我认为）是有意义的。脚本在容器外部（在dir中），我认为容器没有权限在容器外部写入文件，但是通过写入mnt，我正在写入dir，但是通过容器绑定<代码>--cleannev根本不会改变行为——但我想现在文件写入问题已经解决了，不需要改变。如果我能弄清楚