linux 安装报错64-x,安装gid12.0.4linux-x64l后启动报错/liblzma.so.5: no version information available 的解决办法...

在尝试运行GiD 12.0.4版本时,遇到了启动错误,错误信息显示libselinux.so.1依赖的liblzma.so.5版本不匹配。当前系统中libselinux.so.1需要的是liblzma.so.5.0.99,而GiD安装目录下的liblzma.so.5版本未知。为解决这个问题,对GiD安装目录下的liblzma.so.5进行了备份,并创建了一个指向系统中liblzma.so.5.0.99的符号链接,从而修复了版本不对应的问题。

从gidhome.com官网下载安装包gid12.0.4-linux-x64-Install,安装后第一次启动,报错如下

[root@yutong mnt]# ./gid&

Configuring GiD for GLX Rendering

/opt/GiDx64/12.0.4/gid.exe: /opt/GiDx64/12.0.4/lib/liblzma.so.5: no version information available (required by /lib64/libselinux.so.1)

[root@yutong lib]# ls -al liblzma.so.*

-rwxr-xr-x 1 root root 558434 Feb 13 2014 liblzma.so.5

[root@yutong lib]#

.

[root@yutong lib64]# pwd

/lib64

[root@yutong lib64]# ls -al libselinux.*

-rw-r–r–. 1 root root 316560 Jun 10 2014 libselinux.a

lrwxrwxrwx. 1 root root 27 Mar 10 20:20 libselinux.so -> ../../lib64/libselinux.so.1

-rwxr-xr-x. 1 root root 147120 Jun 10 2014 libselinux.so.1

[root@yutong lib64]#

[root@yutong lib64]# ldd libselinux.so.1

linux-vdso.so.1 => (0x00007fff10db9000)

libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fb25e788000)

liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fb25e563000)

libdl.so.2 => /lib64/libdl.so.2 (0x00007fb25e35e000)

libc.so.6 => /lib64/libc.so.6 (0x00007fb25df9d000)

/lib64/ld-linux-x86-64.so.2 (0x00007fb25ec39000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb25dd81000)

[root@yutong lib64]#

从信息可知,当GID启动时,libselinux.so.1需要调用 /opt/GiDx64/12.0.4/lib/liblzma.so.5。但是,目前该版本与libselinux.so.1所能用的版本有不对应,libselinux.so.1对应的是 liblzma.so.5.0.99

[root@yutong lib64]# ls -al liblzma.so*

lrwxrwxrwx. 1 root root 17 Mar 10 20:20 liblzma.so -> liblzma.so.5.0.99

lrwxrwxrwx. 1 root root 17 Mar 17 16:50 liblzma.so.5 -> liblzma.so.5.0.99

-rwxr-xr-x. 1 root root 153184 Jun 10 2014 liblzma.so.5.0.99

故备份 /opt/GiDx64/12.0.4/lib/liblzma.so.5为 /opt/GiDx64/12.0.4/lib/liblzma.so.5.back

做一链接:

ln -fs /lib64/liblzma.so.5.0.99 /opt/GiDx64/12.0.4/lib/liblzma.so.5

[root@yutong lib]# pwd

/opt/GiDx64/12.0.4/lib

[root@yutong lib]# ls -al liblzma.so.5

lrwxrwxrwx 1 root root 24 Mar 17 19:55 liblzma.so.5 -> /lib64/liblzma.so.5.0.99

启动gid

0818b9ca8b590ca3270a3433284dd417.png

0818b9ca8b590ca3270a3433284dd417.png

0818b9ca8b590ca3270a3433284dd417.png

<think>嗯,用户遇到了在远程Linux服务器上使用Docker Compose挂载卷时报错的问题,特别是提示'invalid volume specification'。我需要仔细分析可能的原因和解决方案。首先,根据用户提供的引用信息,特别是引用[3]提到挂载路径必须是绝对路径,而用户可能在Windows和Linux之间的路径格式上有问题。 首先,Docker在Linux上运行时,挂载的宿主路径必须是Linux的绝对路径。但用户可能在Docker Compose文件中使用了Windows风格的路径,比如E:\work\docker\logs,这在Linux下是不被识别的。因此,需要确认路径是否正确转换。 另外,引用[4]提到Windows用户可能会遇到目录共享问题,用户可能试图在远程Linux服务器上挂载本地Windows路径,但Docker守护进程运行在Linux上,无法直接访问Windows的文件系统。这时候可能需要使用SMB或NFS来共享目录,或者在Linux服务器上创建对应的目录结构。 还需要检查Docker Compose文件的语法是否正确,比如卷的声明是否正确使用了绝对路径,并且冒号前后的格式正确。例如,应该是`- /host/path:/container/path`,而如果使用命名卷,可能需要预先创建或者正确配置。 此外,权限问题也可能导致挂载失败,比如Linux上的Docker用户是否有权限访问指定的宿主目录。可能需要修改目录权限或调整SELinux/AppArmor设置。 总结下来,可能的解决步骤包括:检查路径格式是否为Linux绝对路径,使用正确的共享文件系统,调整权限设置,以及验证Docker Compose文件语法。用户可能需要将本地Windows路径映射到远程Linux服务器的路径,或者设置网络共享,确保两者之间的文件系统能够正确交互。</think>### 逐步解答 在远程Linux服务器上使用Docker Compose挂载Windows路径到容器时,出现`invalid volume specification`错误通常由**跨系统路径格式不兼容**或**权限问题**引起。以下是具体解决步骤: --- #### **1. 检查路径格式是否符合Linux规范** - **问题根源**: Docker Compose在Linux服务器上运行时,宿主路径(即宿主机路径,此处为远程Linux服务器的路径)必须使用**Linux绝对路径**(如`/home/user/data`),而Windows路径(如`E:\work\docker\logs`)会被识别为非法格式[^3][^4]。 - **解决方案**: - **方法一**:将Windows路径映射到Linux服务器本地目录 1.Linux服务器上创建目标目录(例如`/mnt/docker_data`) 2. 通过SFTP或文件同步工具(如`rsync`)将Windows本地文件传输到该目录 3. 修改Docker Compose文件中的挂载配置: ```yaml volumes: - /mnt/docker_data:/app/data ``` - **方法二**:使用网络共享协议(如SMB/NFS) 1. 在Windows上共享目标文件夹(如`E:\work\docker\logs`) 2.Linux服务器上挂载共享目录到本地路径(例如`/mnt/windows_share`) ```bash sudo mount -t cifs //windows_ip/share_name /mnt/windows_share -o username=user,password=pass ``` 3. 在Docker Compose中引用挂载后的Linux路径: ```yaml volumes: - /mnt/windows_share:/app/logs ``` --- #### **2. 验证Docker Compose语法正确性** - **常见错误**: - 路径未使用绝对路径(如`../data`或`data`) - 冒号`:`前后缺少空格或路径分隔符错误 - **修正示例**: ```yaml # 错误示例(Windows路径直接引用) volumes: - E:\work\docker\logs:/app/logs # 无效路径 # 正确示例(Linux绝对路径) volumes: - /opt/docker/logs:/app/logs ``` --- #### **3. 检查目录共享权限** - **权限问题**: - Linux服务器上的Docker守护进程(`dockerd`)需要**读写权限**才能访问宿主目录。 - 如果使用SMB/NFS挂载的共享目录,需确保挂载时设置了`uid`和`gid`参数,例如: ```bash sudo mount -t cifs //windows_ip/share /mnt/windows_share -o username=user,password=pass,uid=1000,gid=1000 ``` - 对于本地目录,运行以下命令赋予权限: ```bash sudo chmod -R 777 /opt/docker/logs # 仅限测试环境,生产环境需细化权限 ``` --- #### **4. 其他可能原因** - **Docker守护进程配置**: 如果使用Docker Desktop与远程服务器连接,需确保已启用**目录共享**功能(Windows的Docker设置中勾选对应驱动器)[^4]。 - **SELinux/AppArmor限制**: 在Linux服务器上临时禁用SELinux或调整策略: ```bash sudo setenforce 0 # 临时禁用 ``` --- ### 总结 核心解决思路是**确保挂载路径在Linux服务器上有效且可访问**。若需直接挂载Windows路径,必须通过文件共享协议中转,而非直接引用原生路径。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值