But if I restrict the access to it with an .htaccess-file, I still get this warning.
If I try to access the admin folder I get
Forbidden
You don't have permission to access /mantis/admin/ on this server.
in my browser.

In my installation the web-server is running on a LINUX-machine and the MANTIS-application is actually located on a mounted WINDOWS-folder.
So I would prefer to restrict the access with an .htaccess-file.
Is it possible?

I use SSL with a self-signed certificate.
So PR https://github.com/mantisbt/mantisbt/pull/1151 with the GuzzleHttp-solution is not working for me, because it fails with an exception 'SSL certificate problem' and falls back to the file-based check.
As result I still get the warning regarding the admin-folder, though access to the admin-folder is restricted via .htaccess-file.

and the MANTIS-application is actually located on a mounted WINDOWS-folder
Just out of curiosity, what's the advantage of that?
It's certainly not optimal in terms of performance.

My development-environment is on windows, the app itself is running on a virtual-machine with linux.
I want to have the source files on my windows machine. They are mounted on the linux-virtual machine.
Our production system is completely running on linux - so there the access restriction on operating system level is possible.

Basically yes - but I want to keep the committed files in sync with the production environment as much as possible and want my development-environment behave the same like the production one.
Otherwise I have to maintain 2 versions of config_inc.php.

And as @dregad mentioned, the solution with a check from a web-server point of view has a benefit:

this has the added benefit that the schema-based admin checks are executed, which is not possible when access is disabled at the filesystem level.

See it more as a test-environment, where we try new developments as our users can test their inputs on it, too.

@hloehnert what you might need is some kind of deployment pipeline.
Development -> Test -> Production
Typically you don't want your testers to waste time in using your current development that might contain breaking changes.
A simple script that copies your development environment to test environment without copying the admin directory (or removing it) could do the job.

Otherwise I have to maintain 2 versions of config_inc.php.

That's what I'm doing for best performance when going from Test to Production, set $g_admin_checks = OFF;

There are some more reasons to have own versions of config_inc.php during development, test and production.
e.g. settings like $g_display_errors, $g_show_detailed_errors, $g_stop_on_errors or $g_log_level.

I agree, but the productive-relevant settings in config_inc.php are not explicitly separated from the debug/log-relevant settings.
So keeping own versions of it will produce redundancy, which I want to avoid.

A solution I think about now, is to work with isset($_SERVER['SERVER_NAME']) constructs in config_inc.php to set some configs differently.