<metaname="description"content="After migrating from 1.15 or earlier to gitea 1.16 paths are no longer found and files cannot be created because of permission problems because the default example.ini file changed."/>
<metaproperty="og:description"content="After migrating from 1.15 or earlier to gitea 1.16 paths are no longer found and files cannot be created because of permission problems because the default example.ini file changed."/>
<p>In Gitea 1.15 the <ahref="https://github.com/go-gitea/gitea/blob/cfb4c23a5009b9c236d48ac0bc156577c7d70741/custom/conf/app.example.ini">app.example.ini</a> file was changed to <ahref="https://github.com/go-gitea/gitea/commit/4a84022d2559ccfc99960c7c654ee8b9b38664f7">comment out most of the values</a>. The assumption was that all values exactly matched the defaults <ahref="https://github.com/go-gitea/gitea/blob/main/modules/setting/setting.go">in the source code</a>. However, there are differences, for instance for <ahref="https://github.com/go-gitea/gitea/blob/cfb4c23a5009b9c236d48ac0bc156577c7d70741/modules/setting/setting.go#L771">APP_DATA_PATH</a>. Before Gitea 1.15, <code>app.example.ini</code> contained:</p>
<prestyle="background-color:#2b303b;color:#c0c5ce;"><code><span>APP_DATA_PATH = data
</span></code></pre>
<p>and the path was relative to the <strong>directory from which the Gitea server was running</strong>. In Gitea 1.15 up to 1.16, it was commented out:</p>
<prestyle="background-color:#2b303b;color:#c0c5ce;"><code><span>; APP_DATA_PATH = data
</span></code></pre>
<p>and the path was relative to the <strong>work path directory</strong>, as provided either via the --work-path argument or the <code>GITEA_WORK_DIR</code> environment variable. </p>
<p>When a distribution such as voidlinux <ahref="https://github.com/void-linux/void-packages/blob/master/srcpkgs/gitea/patches/config.patch">uses app.example.ini</a> as a base for the Gitea package, this change indirectly creates a regression and an upgrade of Gitea <ahref="https://github.com/go-gitea/gitea/issues/19367">fails with errors</a> such as <code>unable to open level db at data/data/queues/common: mkdir data: permission denied</code>. The regression did not show as soon as Gitea 1.15 became available in voidlinux because the package <ahref="https://github.com/void-linux/void-packages/blob/7fc9190f0e0d557dd5031e68df4e183892d4315b/srcpkgs/gitea/patches/config.patch#L62">explicitly set <code>APP_DATA_PATH</code></a>. But this <ahref="https://github.com/void-linux/void-packages/commit/19d986a2cae9ce73d32552ddb62443b5e7fa13e2">changed when Gitea 1.15.6 was packaged</a> and once the value was commented out, upgrading triggered the problem. This was worked around six month later with the <ahref="https://github.com/void-linux/void-packages/commit/44b6c96fa12ce9d993c7a2ac9486d892735b7e3a">Gitea 1.16.8</a> package.</p>
<p>The <code>APP_DATA_PATH</code> directory is not the only one, the <code>[log] ROOT_PATH</code> is another example. There is an <ahref="https://github.com/go-gitea/gitea/pull/19815">ongoing effort</a> to improve the situation in Gitea 1.17. With the downside of introducing breaking changes that will have an impact on all Gitea installations because the content of the <code>app.ini</code> file will be interpreted differently. In the case of <code>APP_DATA_PATH</code>, both:</p>
<prestyle="background-color:#2b303b;color:#c0c5ce;"><code><span>APP_DATA_PATH = data
</span></code></pre>
<p>and:</p>
<prestyle="background-color:#2b303b;color:#c0c5ce;"><code><span>; APP_DATA_PATH = data
</span></code></pre>
<p>will be interpreted to be relative to the <strong>work path directory</strong>, as provided either via the --work-path argument or the <code>GITEA_WORK_DIR</code> environment variable. Every Gitea installation using <strong>APP_DATA_PATH = data</strong> will need to update the value to be an absolute path such as <strong>/var/lib/gitea/data</strong> so that it keeps pointing to the expected directory.</p>
<p>In order to prepare for the change or ensure the consistency of all path, there fortunately is a very simple <strong>solution: always use absolute paths in the <code>app.ini</code> configuration file</strong>.</p>
