为什么只能访问服务器的var，网站根目录访问权限怎么设置？

服务器的var目录之所以成为唯一能让你随便逛的区域，是因为其它目录要么是系统核心区域不准你碰，要么是用户私人领地不给你看，而var从设计之初就是存放运行日志、缓存、临时文件这些“可变数据”的公共仓库，天然需要向服务进程开放权限。

很多新手站长第一次登录服务器时都会犯嘀咕：根目录下有etc、usr、home这么些个文件夹，怎么查个日志找来找去最后只能进var里操作？去其它目录不是报权限不足就是根本没文件，这篇文章就拆开揉碎了讲清楚，var目录在服务器里到底扮演什么角色，权限墙又是怎么砌起来的。

服务器目录的“各自分工”：为什么偏偏是var

服务器文件系统不是随便分几个文件夹完事,它有一套像人类社会一样的组织架构，每个目录的权限和定位都卡得死死的，谁也越不过谁的界限。

根目录“/”和家目录“/home”为什么进不去

根目录是整个Linux系统的地基,里面住着/bin（系统必备命令）、/etc（全局配置文件）、/usr（系统应用）等核心住户，普通用户对这些目录只有“路过看一眼”的权限，想看文件内容基本被拦截，更别说动手改了，这套机制是为了防止有人误删或者篡改系统文件，一旦出事整台服务器就瘫了。

家目录/root或/home/xxx就更离谱了，那是系统管理员或者每个用户自己的卧室，卧室的钥匙只配给房主和最高权限的管理员root，其他用户想进去，门都打不开，行业共识认为，服务器安全的第一道防线就是目录隔离。

var目录的定位：公共休憩区

var的全称是variable,意思是“可变数据存储区”，它不像/etc那样几乎恒定不动，也不像/home那样带私人属性，它就是给服务器上跑的各种软件、服务提供一个随时能写东西的公共场地。

例如网站程序要写日志,Nginx要存访问记录，软件包管理器要放缓存，邮件系统要排队收发，这些全都往var下面丢，var就像一个24小时有人值班的快递转运站，货来了就放这儿，程序需要就自己来取，为了让这功能正常运转，系统设计者把所有业务进程对var的访问权限设成了“默认开放”，这就是为什么你能进var目录。

var目录权限机制：这才是“只能访问”的根本原因

权限体系分成三档读、写、执行，再加上身份划分所有者、所属组、其他人，var目录的常见权限值一般是755或775，也就是所有者能完整读写，同组的用户有权限进来，其它用户也能读和执行文件，而/home或/etc这类敏感目录往往设成700或600，意思就是除了root主人，其他人都得吃闭门羹。

为什么你用的不是root

大部分服务器环境（虚拟主机、宝塔面板、云主机）日常使用的都是普通用户身份，比如一个叫www或admin的账号，普通用户对上文提到的系统目录没有任何权限，唯一能自由操作的就剩var下面对当前用户开放的子目录，例如log、tmp、cache。

这是安全圈子里默认的分层防守策略：即便网站被人搞出个后门，攻击者最多也只能在var这个公共区里捣鼓，无法直接摸到系统内核文件，业内专家指出，将权限细分到目录级别，能有效减弱单一入侵点带来的连锁风险。

子目录权限各有各的玩法

var下面是另一个独立世界,不同子目录服务于不同任务：

即便都在var大伞下,具体到某个文件夹，能不能访问依然由它自己的权限位決定，你看到的现象能进var却进不了var里更深一层的某些目录，主要是子目录权限又单独做了收紧。

实际运维中怎么安全搞定var目录访问

光理解原因不够,真正上手时你还需要一套可落地的操作路径，让你在“能访问”的基础上干更多正事。

查看var下所有目录权限

把下面这行代码敲进终端,就能把底细看得一清二楚：

ls -l /var/

当你看到drwxrwxr-x这种开头的行，含义是所属用户和组可读写，其他用户只可读可执行，若你发现某个日志目录进不去，查看一下所属用户是谁，再用groups 用户名确认自己在不在这个组里面。

想进某些受限日志目录的“窍门”

如果你需要查看运行中的网站错误日志,但路径里包含/var/log/nginx/error.log，普通权限可能不够用，此时最稳妥的方式是执行：

sudo tail -f /var/log/nginx/error.log

sudo命令让你以管理员身份临时过一下门槛,但不直接改变目录权限，避免环境被搞乱，你要是天天要查日志，可以把自己加入对应日志目录的所属组，

sudo usermod -aG adm 你的用户名

添加完组后重新登录,再进/var/log就能顺畅多了。

服务器var目录怎么清理最稳

var容量被写满的问题是运维过程中高发的一类事故,要清理缓存，可以优先考虑安全清理软件包缓存：

sudo apt clean

或者使用du -sh /var/log/找出大文件，确认当前不再使用的日志直接清空，整理时一定要避开正在写的文件，否则日志文件句柄出问题会导致程序崩溃。

排查问题：nginx访问不到var目录的常见场景

一般来说你确实能访问var,但总有例外，当你部署nginx或者对网站做安全加固时，偶尔会遇到“nginx访问不到var目录”的报错，这往往不是因为服务器把你挡了，而是nginx进程本身权限不够。

根因通常是软链接和SELinux

每次给站点根目录做软链接指向/var/www时，如果SELinux开着，它默认不让httpd进程跨目录读取var里的文件，这时需要手动调整上下文：

sudo setsebool -P httpd_read_user_content 1
sudo chcon -R -t httpd_sys_content_t /var/www

如果你是用的宝塔面板装的环境,这类带目录延伸的问题多半出在防跨目录配置上，直接到面板的“网站设置”->“目录权限”里面打开对应开关就能处理。

数据目录该放哪道理一样

很多站长在配置网站数据存储时会纠结路径选择,从安全角度看，数据文件和临时文件都该放在var下的目录，这样即便主站程序被上传了木马，它也只能在var里面折腾，没法扩散到系统其它层级，无意中就把攻击面限制在了可控范围内。

顺着var权限逻辑反推整个服务器

理解了“为什么只能访问服务器的var”，其实帮你看透了一环更大的棋局，服务器上每个目录的开放程度，都对应着一层业务需求和安全妥协，var承担太多临时性、可变化内容的收纳任务，因此被设计成了这个“半开放”状态。

日常维护策略很简单：能进var就按权限办事，绝不越权改其它目录；该用sudo的场合就用sudo；在服务器上做任何变更前，先确认和var相关的站点日志路径，只要把var这个公共仓库管明白，服务器上的大多数运行问题你都能找到线索，这也算是权限之外，var目录给运维人留下的一份“隐藏答卷”。

Q&A：var目录使用常见疑问

为什么服务器上其它目录完全看不了？

其它目录比如/proc、/sys属于内核运行时生成的虚拟文件，普通用户既不该看也看不懂；/boot存放启动文件，是服务器启动的命根子，一旦误改系统直接GG；/etc所有权属于root，普通用户读写都受限，这些目录的共同特征是绝大多数用户根本不需要直接操作它们。

修改var目录权限会有风险吗？

有风险,如果把/var/log的权限从750改成777，意味着任何用户都能读取系统日志内容，这等于把登录信息、错误堆栈、服务调试细节全部白送出去，比较合理的做法是按需调整，只改某个子目录的属主或组，不要对整个var目录做权限松动。

nginx错误日志位置找不到了怎么办？

执行nginx -T或直接查看/etc/nginx/nginx.conf里的error_log配置项，确认路径后执行sudo ls -l /var/log/nginx/，如果目录为空先确认nginx是否已重启过，若长期不产生日志，大概率是目录属主变更导致写失败，你也可以执行sudo find /var/log -name "error" -type f全盘搜出日志文件位置。