由于Ubuntu官方源上的软件版本都太低了（比如nodejs的版本只有0.6），不得不把开发环境转移到Fedora上，而且Fedora属于RHEL系，操作上与Red Hat/CentOS相似。虽然网上都说Fedora是Red Hat的试验品，也没太在意。直到用到了systemd，才发现有多坑。
事情从运行nginx开始（Fedora在VMware中，nginx是使用yum安装的，自带systemd的service，根目录设置在/mnt/hgfs/www），可是用systemctl启动的nginx无法访问根目录（浏览器报403，autoindex已开，日志说permission denied，目录权限777，以前在Ubuntu中都是正常的），但是改到默认的/usr/share/nginx/html就正常了。
一开始觉得是vmhgfs的问题，百度来谷歌去也没什么相关的内容。
后来想那我不用vmhgfs不就ok了，于是新建了一块硬盘，分区格式化（ext4）后mount到/www，结果又是403！
后来尝试了直接运行nginx结果根目录设在哪都不会报错，包括前面的vmhgfs。那就说明问题不是出在vmhgfs上，既然用systemctl跑的nginx和直接运行的结果不同，那么问题一定就出在systemd上。
研究了nginx.service也没有发现任何问题，包括一行一行地注释掉也无效，反正只要不是/dev/sda上的文件系统就报403。
再想能不能不用systemctl来启动nginx，以前在Ubuntu下使用rc.local来启动nginx就一直很正常，于是尝试了新建rc.local来启动nginx，nginx是起来了，结果还是403。后来想想这里的rc.local也是通过systemctl起来的，还是绕不开systemd。
转向去研究systemd，发现这是SysV的替代品，在Fedora 16的时候就应用了。但是网上的资料不多。
最后把根目录设为/，发现少了三个目录，分别是/root /www /lost+found。三者的权限都不同，/lost+found的是700，/root的是550，而/www的是755。连755的目录都无法显示出来没道理啊，700的也应该是无法进入而不是不显示啊，而且同样挂载方式的/boot都能显示出来。尝试进入/home时又报403了，/home是755的权限。真不知道nginx是以谁的权限访问目录了。最后推断问题只能出在systemd对文件系统的管理上了。