This forum is closed to new posts and responses. New discussions are now taking place in the IBM Developer Answers forum.


May 29, 2017, 1:50 AM
25 Posts
topic has been resolvedResolved

ATTEMPT TO ACCESS DATABASE mail\xx.nsf by SERVER//aswo was denied

  • Category: Administration
  • Platform: Windows
  • Release: 9.0.1
  • Role: Administrator
  • Tags:
  • Replies: 7

Hi !
for some users I get the following log entries:

>> ATTEMPT TO ACCESS DATABASE mail\xx.nsf by SERVER/aswo was denied

I understand the message, but I don´t understand , why ?!

The called server is part of the group "LocalDomainServers" and that group is part of the ACL of the users.(as SERVERGROUP and MANAGER access).

So, I don´t understand, where this message is coming from.

Maybe someone can help me.

Thanks.

 

Steffi

 

May 30, 2017, 6:51 PM
196 Posts
Here are some troubleshooting steps

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.

 

 

 

May 31, 2017, 6:33 PM
362 Posts
I'm sure a lot of people have different ways to diagnose this.

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.

Jun 1, 2017, 7:04 AM
25 Posts
thanks for help

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.

 

 

Jun 1, 2017, 9:08 AM
329 Posts
Are the affect users all on the same server?

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.

Jun 1, 2017, 10:11 AM
362 Posts
aha. you say its just certain DBs. Hm.

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.

Jun 23, 2017, 4:17 AM
25 Posts
..installed traveler 9.0.1.18

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.

Jul 4, 2017, 10:40 AM
25 Posts
... traveler update 9.0.1.18 was the solution

 


This forum is closed to new posts and responses. New discussions are now taking place in the IBM Developer Answers forum.