You've already verified that the user type for LocalDomainServers is entered correctly (as Server group rather than as Server), so I would try the following:

Add SERVER/aswo individually to the ACL. If the server then has access, I would suspect that the ACL for LocalDomainServers is corrupt or the server name is entered incorrectly in the group.

Remove and re-add SERVER/aswo from LocalAdminServers. When you re-add the server, do so by using the dropdown, and select the name of the server from the Domino Directory.  I have seen cases in which the server's name was entered incorrectly.

Verify that there is not more than one entry for LocalDomainServers in the Domino Directory.

Some pointers:

In the ACL dialog, there's an "Effective Access" button. Check out your server's access through the button. If it's not getting through, this button will tell you.

What access do you expect this server to have? Is it the local server, or an external server? Is an agent trying to access the database, or is a replication task trying to?

Groups are tagged as to whether they're access-only, multipurpose, mail-only, deny-access list. "Access Only" and "Multipurpose" are the only right answers to grant access.

Your server, group, at every instance must be typed in correctly.

Address Book corruption can happen; it's not as likely as simple typos.

Hi !

thanks for your hints.

I checked everything around the "LocalDomainServers" group. -> everything ok.
I also added the server in the acl with Manger access and check it with "Effective Access" -> ok, too.

But there´re still the entries in the log-file.

This server is our "IBM Traveler" server (internal) , which is part of the "LocalDomainServers" with Manager-Access on all maildatabases.

The maildatabases  which are producing the "error" are Traveler Users.

But just a few, not all users are effected.

Check the Server Document -> Security tab -> Server Access -> Trusted Servers (all the way at the bottom). Ensure that either the  "LocalDomainServers" group is listed there, or at least your Traveler server.

That being true ... and other DBs are truly replicated from your logging server to the Traveler server, you should be able to see the replication events in "replication history".

If all this is true (that is, you confirm another database on the same server is allowing/granting access), the attempt to access the database itself seems to be the problem.

Do you know if there are agents trying to reach the database? Or is it exclusively replication that's occurring?

More likely: if exclusively replication, we're down to, the database isn't really granting access. It'd have to be checked using an API call to be sure, but sometime y'can discover what's up by inspecting the ACL entry very carefully.

Less likely: if not, that is, if you have an agent "reaching over" to get something from the source server, OR simply an agent running on the source server, but signed by the Traveler server -- make sure the agent looks like it has the right signer name, and that the agent was signed / saved after you last refreshed the signer's certificates.

On this last situation Mark is dead right: a "reaching over" agent requires the server be trusted. The agent signer also must have enough access to do the job.

after installing the traveler update 9.0.1.18 no more messages are displayed. Maybe that´s the solution. I´ll wait and check the log files.