向 Solr 核心添加字段时，为啥会出现“ManagedIndexSchema Error persisting managed schema => FileNotFoundException:

Posted 2023-02-23

【中文标题】向 Solr 核心添加字段时，为啥会出现“ManagedIndexSchema Error persisting managed schema => FileNotFoundException: (Access is denied)”？

【英文标题】：Why do I get "ManagedIndexSchema Error persisting managed schema => FileNotFoundException: (Access is denied)" when adding a field to a Solr core?向 Solr 核心添加字段时，为什么会出现“ManagedIndexSchema Error persisting managed schema => FileNotFoundException: (Access is denied)”？

【发布时间】：2022-01-14 11:23:06

【问题描述】：

我有一个在 windows 上运行的 java 程序：

使用“bin/solr.cmd restart -f -q -p 55183”运行 Solr 服务器。 使用“bin/solr.cmd delete -c my_core”删除（如果存在）名为“my_core”的旧内核。 使用“bin/solr.cmd create -c my_core”创建一个名为“my_core”的新核心。 使用以下方法配置方案： “bin/solr.cmd config -c my_core -p 55183 -action set-user-property -property update.autoCreateFields -value false”。 使用 solrj 的 HTTP 客户端向方案中添加一个新字段。 做更多的事情，包括索引一些文档。

在我的机器上一切正常，但是当我将它发送到公司的服务器场进行测试时，第 5 步（添加字段）失败。

Solr 服务器返回的错误是： 2021-12-07 19:58:00.183 错误 (qtp966739377-20) [x:my_core] oassManagedIndexSchema 错误持久托管模式 C:\views\clones\clone2\0\Qrelease\3rd\Solr\server\solr\my_core\ conf\managed-schema => java.io.FileNotFoundException: C:\views\clones\clone2\0\Qrelease\3rd\Solr\server\solr\my_core\conf\managed-schema（访问被拒绝）

客户端返回的错误是： org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException：来自 http://localhost:55183/solr/find_it_core 的服务器出错：错误处理命令：responseHeader=status=400,QTime=60,error =metadata=error-class=org.apache.solr.api.ApiBag$ExceptionWithErrObject,root-error-class=org.apache.solr.api.ApiBag$ExceptionWithErrObject,details=[无法持久化托管模式。错误持久化托管模式 C:\views\clones\clone2\0\Qrelease\3rd\Solr\server\solr\my_core\conf\managed-schema],msg=error processing commands,code=400

任何想法为什么我能够在我的计算机上更改方案但不能在远程计算机上进行更改？

【参考方案1】：

当您使用 Solr 的 HTTP API 添加新字段时，会导致将新字段定义添加到 managed-schema 文件中。

它可以在您的机器上运行，因为文件 managed-schema 存在并且您拥有对它的写入权限。

服务器环境的错误表明该文件在服务器上不存在，所以我首先要确保核心的创建与您在本地环境中所做的相同，并确保该文件确实存在.

当文件确实存在但运行 Solr 的用户没有对它的写入权限时，我也看到了类似的问题。

【讨论】：

我在运行时创建核心作为代码流的一部分。因此，运行代码的机器（和用户）会创建方案（作为“创建核心”阶段的一部分）并尝试将字段添加到其中。

我唯一的猜测是，即使您在服务器上运行与在本地计算机上相同的步骤，Solr 也可能在服务器上的不同用户（例如系统帐户）下运行，这与您在同一服务器上的帐户具有不同的访问权限。

【参考方案2】：

我遇到了同样的问题，但已解决。以下是我的问题的详细信息：

在 php 的生产服务器上运行良好，我通过 URL 中的每个请求发送凭据。这种方式已经使用了很长时间了。 移植到我的测试服务器上的solrj，配置和生产一样，只不过是一台运行ubuntu-18.04+tomcat-10.0.12+solr-8.8.1+mysql的服务器，而不是前面的tomcat -end 和 solr+mysql 在后端。除了生产 DMZ 之外，安全设置是相同的。在测试服务器上一切正常。 将 solrj 实现移至前端服务器并出现身份验证错误 (IOException)。 将 PreemptiveAuthInterceptor（例如，参见 Solr basic authentication without setting credentials for each request）添加到我的 httpClient 到 solrj，现在一般的身份验证问题消失了，但我开始遇到与您相同的错误。

我还检查了@HectorCorrea 的建议，但 solr 以 solr 用户身份运行，该用户还拥有托管模式文件。顺便说一句，在错误之前创建了字段 - 我可以在托管模式文件中看到它，并且在通过 Rest API 访问模式时也可以看到它。如果我的解决方案对您没有帮助，请尝试检查这些。

无奈之下，我只是重新启动了 solr 服务并再次尝试。现在 PHP 和 solrj 实现都可以工作了。有趣的是，我在日志文件中的其他错误在创建新内核和添加字段时也消失了，而 PHP 没有发生这种情况：

o.a.s.c.ConfigSetProperties Did not find ConfigSet properties, assuming default properties:  => org.apache.solr.core.SolrResourceNotFoundException: Can't find resource 'configsetprops.json' in classpath or '/var/solr/data/my_core'
    at org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:402)

还有

o.a.s.m.SolrMetricManager Error loading metrics reporter, plugin info: type = reporter,name = default,class = org.apache.solr.metrics.reporters.SolrJmxReporter,attributes = name=default, class=org.apache.solr.metrics.reporters.SolrJmxReporter, => javax.management.RuntimeMBeanException: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.reflect")
    at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:829)

最后是

o.a.s.h.RequestHandlerBase org.apache.solr.api.ApiBag$ExceptionWithErrObject: error processing commands, errors: [Unable to persist managed schema. Unable to reload core [my_core]],
    at org.apache.solr.handler.SchemaHandler.handleRequestBody(SchemaHandler.java:97)

要查看我的经验是否与您的一致，您可能会查看日志中是否出现类似错误。

我不清楚这为什么有效，因为 Solr 的 .xml 文件中没有任何变化。我将避免猜测可能导致此问题的原因，但我还要提到我的 solrj 版本在测试服务器和生产服务器上都是 8.11.0，这与任何一个上的 solr 都不匹配。请尝试重新启动并检查我上面提到的其他事项。

【讨论】：

感谢您的详细解答！我不明白你是如何修复我得到的错误的。您写道，添加 PreemptiveAuthInterceptor 修复了您的 Auth 错误并导致了我的错误。然后你写了“沮丧的是，我刚刚重新启动了 solr 服务并再次尝试。现在 PHP 和 solrj 实现都可以工作了”。这意味着您认为即使我没有收到 Auth 错误，我仍然应该使用 PreemptiveAuthInterceptor 并希望它能解决我的文件权限问题？

David，如果您没有使用 PreemptiveAuthInterceptor，请尝试将其添加到您的 Java 中。似乎 solrj 正在进行一些优化，并且不会在每个请求上发送授权，除非您明确执行或使用 PreemptiveAuthInterceptor。另外，您在工作服务器上的 solr 服务器实例和您的 solrj 版本是否相同？我相信在我解决了所有其他问题之后，可能是版本不匹配导致服务器出现问题，直到我重新启动它。