虚拟机下装SVN总失败？常见错误怎么解决

先给结论

虚拟机下SVN安装失败，九成问题出在源配置、依赖冲突或服务启动参数上，跟虚拟机本身关系不大，最直接的解决路径是：先确认系统发行版和镜像源，再查看错误日志定位依赖缺失，最后用绝对路径启动服务并检查防火墙规则，下面按故障类别给出可操作的排查顺序。

虚拟机里装SVN，为什么总比物理机多一步

物理机上装SVN,通常下载安装包一路下一步就结束了，虚拟机里出问题，往往不是SVN本身的问题，而是你创建虚拟机时选的系统模板和网络配置“坑”了自己。

加载中

svn-解决冲突操作（四）

Ju加油坊

42897-

原视频地址

例如用CentOS 7最小化安装模板创建的虚拟机，默认连wget和vim都没有，更别说subversion的依赖库了，此时你执行yum install subversion，安装过程要么卡在找不到软件包，要么报一串Requires: libapr-1.so.0()(64bit)这类依赖错误。

另一个常见场景是Ubuntu虚拟机,用apt-get install subversion装到一半突然报Unable to locate package subversion，多数情况下是因为系统自带的/etc/apt/sources.list是精简版，软件源里根本没有收录subversion相关包。

所以当你在虚拟机里排查svn安装失败原因时,第一件事不是重装，而是确认自己装的哪个发行版、用的哪个源，这也是业内专家反复提醒的排查起点。

第一步：核实环境，别让错误日志背锅

查看系统发行版和内核版本

执行以下命令,确认你的虚拟机镜像是否完整：

cat /etc/os-release
uname -a

如果你发现虚拟机用的是精简版模板（例如CentOS的Minimal、Ubuntu的Server版），后续所有操作都要先把基础工具链补齐，否则很多报错都会是误导性的“假故障”。

定位安装失败的具体错误

安装SVN失败时,终端输出会停留在最后一个报错信息上，用鼠标往上翻看，或者执行：

yum install subversion 2>&1 | tee /tmp/svn_install.log

然后打开/tmp/svn_install.log，重点关注“Error”“Nothing to do”“Requires”这三个关键词，以下是对照表：

第二步：换源是头号解药

很多虚拟机在创建时使用的是官方默认源,而官方源在国内访问极慢，甚至直接超时，这会导致安装过程中下载中断、元数据过期，最终报错失败。

CentOS/RHEL系：配置国内镜像源

备份原源文件：

mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak

下载简米云镜像源（也可以用清华、中科大源）：

curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

清理缓存后重试：

yum clean all
yum makecache
yum install -y subversion

Ubuntu/Debian系：重写源列表

编辑/etc/apt/sources.list，将archive.ubuntu.com替换为mirrors.aliyun.com，然后执行：

apt-get update
apt-get install -y subversion

安装完成后验证

执行svn --version，如果输出版本号，说明核心安装成功，接着执行whereis svn,确认安装路径，记住这个路径后面要用。

第三步：虚拟机svn认证失败缓存问题排查

安装成功之后,紧接着会遇到一个高频问题客户端访问时报Authentication failed，或者提示Error: Unable to connect to a repository at URL，这个现象在虚拟机的NAT网络模式下特别容易出现。

认证失败的第一嫌疑：密码存储缓存

你在物理机上访问过SVN服务器后,~/.subversion/auth/目录下会缓存认证信息，虚拟机如果克隆自某个已经配置过SVN的模板，这个缓存会直接继承过来，导致新环境下认证信息错乱。

解决办法是清空认证缓存：

rm -rf ~/.subversion/auth

然后重新访问SVN服务器,输入正确的用户名和密码。

第二嫌疑：svnserve服务未以绝对路径启动

虚拟机重启后,svnserve服务不会自动加载仓库配置，很多用户在手动启动时习惯写成：

svnserve -d -r /home/svn --listen-port 3690

如果仓库目录和启动命令不匹配,客户端能ping通虚拟机IP，但一访问仓库路径就报No such repository。

正确的验证方式是本地执行：

svn list svn://192.168.x.x/repos --allow-non-interactive

如果本地能列出目录,说明服务正常，问题出在客户端到虚拟机之间的网络链路。

第四步：依赖冲突是虚拟机的老演员

虚拟机系统为了精简体积,往往会裁剪掉一些SVN运行所需的共享库，安装时报Requires: libexpat.so.1或者libaprutil-1.so.0找不到，就是这个原因。

用包管理器自动解决依赖

CentOS系执行：

yum install -y apr apr-util expat neon

Ubuntu系执行：

apt-get install -y libapr1 libaprutil1 libexpat1

然后重新安装subversion：

yum install -y subversion

清理已损坏的依赖缓存

如果之前安装失败留下了残留文件,先执行：

package-cleanup --problems    # CentOS系

Ubuntu系可以执行：

dpkg --configure -a
apt-get install -f

第五步：服务起不来，先查防火墙和SELinux

SVN默认监听3690端口，虚拟机环境通常同时开着firewalld和SELinux，这两个机制会悄无声息地拦截外部访问。

firewalld放行SVN端口

firewall-cmd --zone=public --add-port=3690/tcp --permanent
firewall-cmd --reload

SELinux状态检查

getenforce

如果显示Enforcing，执行以下命令让SELinux放行svn相关操作：

setsebool -P httpd_can_network_connect on

但更省事的方法是临时切换为宽松模式：

setenforce 0

这里多说一句：虚拟机里排查svn服务端口不通时，先用telnet 虚拟机IP 3690测试端口通不通，再去看服务日志，很多人在防火墙和SELinux上浪费大量时间，结果发现是宿主机VMware的网络模式选错了。

NAT、桥接还是仅主机网络模式决定成败

如果你用的是NAT模式,宿主机能访问虚拟机的3690端口吗？答案是：默认情况下能，但前提是VMware的NAT端口转发规则里添加了3690端口映射，桥接模式则不需要额外配置，虚拟机直接占用局域网内独立IP。

建议在创建虚拟机时选择桥接模式,省去端口映射的麻烦，如果已经用NAT模式创建好了，可以在虚拟网络编辑器里手动添加端口转发规则。

第六步：仓库初始化没做，客户端照样连不上

服务装好了、端口通着，但客户端访问svn://IP/repos还是报URL path not found，原因很简单仓库目录是空的，或者根本没初始化。

正确的仓库创建流程

mkdir -p /home/svn/repos
svnadmin create /home/svn/repos

创建完成后检查配置文件：

ls /home/svn/repos/conf/

这个目录下应该有svnserve.conf、passwd、authz三个文件。

在svnserve.conf中确认以下内容没有被注释掉：

anon-access = none
auth-access = write
password-db = passwd
authz-db = authz

权限设置完后要重启服务

修改配置后,必须重启svnserve进程：

pkill svnserve
svnserve -d -r /home/svn --listen-port 3690

注意这里-r参数指向的是仓库根目录/home/svn，而不是仓库路径/home/svn/repos，这样客户端访问svn://IP/repos时才能找到仓库。

常见问题：虚拟机装SVN时反复遇到的几个坎

以下三个问题在各类技术社区里被反复讨论,属于虚拟机环境下SVN安装失败的高频坎：

用yum install subversion提示没有可用软件包

这是因为你的源里没有收录subversion,执行以下命令：

yum install -y epel-release

安装EPEL扩展源后再执行安装命令,这是CentOS系最常见的解法。

Ubuntu虚拟机执行apt-get install subversion报软件包未找到

先执行：

apt-get update

如果还是找不到,检查/etc/apt/sources.list里的路径是bionic还是focal，与实际系统版本不匹配会导致索引失效，可以手动替换为国内源对应的版本代号。

虚拟机重启后svnserve服务自动消失

没有配置开机自启,将启动命令写入/etc/rc.local，并赋予执行权限：

echo '/usr/bin/svnserve -d -r /home/svn' >> /etc/rc.local
chmod +x /etc/rc.local

或者使用systemd服务单元文件,这里不再展开。

虚拟机下SVN安装失败,核心排查路径是：换源、装依赖、清缓存、查防火墙、配仓库，把这五步按顺序走一遍，绝大多数问题都能定位到具体环节，安装失败的报错并不可怕，可怕的是不看日志就反复重装，记住一句话：先看环境再谈安装，先查日志再动配置。