Das Notes Forum
Domino 9 und frühere Versionen => ND9: Administration & Userprobleme => Thema gestartet von: schroederk am 05.06.14 - 13:15:59
-
Hallo,
ich habe eben an einer kleinen selbstgeschriebenen DB nach einer kleinen Ewigkeit eine kleine Änderung an einem Agenten vorgenommen und wollte nun diese Datenbank wieder mit der Server-ID signieren, wie sonst auch.
Nun erhalte ich aber beim Versuch bei dieser DB die Fehlermeldung "Sie sind zur Durchführung dieser Operation nicht berechtigt".
Auch als "Administration mit voller Berechtigung" dieselbe Fehlermeldung.
Sowohl die Server-ID als auch die ID von mir hat sich nicht geändert. Aber es liegen natürlich ein paar Upgrades des Domino zwischen der letzten und der aktuellen Änderung.
Kann mir einer die Ursache hierfür verraten?
-
Hi.
Darfst Du das denn laut Serverdokument auch?
Adressbuch, Konfiguration, Server, alle Serverdokumente, Reiter Sicherheit, Rechts Einschränkung der Programmierbarkeit.
Aber da hast Du sicherlich schon geschaut?
-
Geschaut habe ich da nicht, aber da ich jetzt festgestellt habe, dass ich gar keine DB mehr mit der Server-ID signieren kann, habe ich natürlich jetzt auch nachgeschaut.
Als berechtigt sind die beiden Gruppen LocalDomainServers und LocalDomainAdmins eingetragen.
Der Server ist korrekt in der Gruppe LocalDomainServers eingetragen.
Ich bin in der Gruppe LocalDomainAdmins.
-
Ich habe hier noch einen Thread für Notes 8 gefunden, der ziemlich genau mein Problem widerspiegelt:
http://atnotes.de/index.php/topic,53072.0.html
Allerdings gab es da auch keine Lösung. Da muss ich wieder einen PMR aufmachen?
-
Wenn Du Deine Notes-ID direkt in die entsprechenden Felder einträgst und den Server neu startest, dann funktioniert das.
Es gibt auch einen SPR JLEN9EGHYU wo das Problem auftritt, wenn Du Deinen Namen im lokalen names.nsf als Kontakt eingetragen hast bzw in den letzten Kontakten drin stehst.
Mit Lotus Notes 9.0.1FP1 habe ich den Fehler nicht mehr bekommen...
Gruß,
Thorsten
-
Sowohl der Domino als auch der Client sind 9.0.1FP1 und ich habe den Fehler.
Ich sehe es nicht als Lösung jetzt IDs direkt in die Felder einzutragen. Dafür gibt es ja die Gruppen.
Ich werd also doch einen PMR aufmachen. :(
-
Habe meinen Text nochmal editiert... schau mal ins lokale names.nsf ob da irgendwo Dein Name drin steht (lokale Kontakte oder letzte Kontakte). Nach dem Entfernen, den Client schliessen und neu starten.
Ansonsten PMR aufmachen, hatte ich neulich auch bei einem Kunden.
-
Habe mich aus den letzten Kontakten herausgenommen, aber keine Änderung.
Ich bin zwar auch in meinem lokalen Adressbuch, aber den Eintrag möchte ich erstmal nicht löschen müssen.
Mache einen PMR auf.
-
Dann trifft ziemlich sicher der von mir aufgeführte SPR bei Dir zu... geb den in Deinem PMR an.
-
Hast Du einen Link zu diesem SPR? Weder der Suche bei IBM noch bei google finde ich etwas.
-
hier (http://atnotes.de/index.php/topic,57251.0.html) der Link zu dem Thread, bei dem das vor kurzem behandelt wurde. Und die Erfahrung habe ich auch gemacht: Nimm Dich raus aus den Recent Contacts und aus Deinem persönlichen Adressbuch, starte den Client neu und voila... funktioniert wieder
-
Ok, ich kann es also auch bestätigen, dass das Entfernen des eigenen Namens aus den eigenen Kontakten das Problem lösen konnte. (Das Löschen aus den Recents reichte nicht)
Ich habe den SPR an den PMR angehangen.
Obwohl ich eigentlich täglich das Forum besuche, sind mir die Threads zum selben Thema nicht aufgefallen. Witzigerweise musste ich erst die Fehlermeldung in Google auf englisch suchen, dann wurde ich fündig ;)
-
IBM hat sich gerade telefonisch gemeldet und angekündigt, dass sich die Entwicklung mit mir in Verbindung setzen möchte um einen Hotfix zur Verfügung zu stellen. Man darf also gespannt sein...
-
Ich hatte das gleiche Problem auch vor ein paar Monaten; und vor einer Woche habe ich genau das gleiche Verhalten auch bei einem Kunden während einer Remote Session beobachtet.
Scheint also irgendein "Feature" in 9.x zu sein. An einer Lösung wäre ich auch interessiert ...
-
http://www-10.lotus.com/ldd/ndseforum.nsf/xpTopicThread.xsp?documentId=FF437D50DE32C21485257CA000720107
-
ist/wird in 9.0.1 FP2 gefixt
-
Uli hat recht, ist in 901FP2 gefixt.
Hatte ich übrigens auch schon und es hilft definitiv nur das Löschen aus den Recent Contacts und des Contacts selbst...
LG, Rainer
-
In der Fixlist vom SP2 kann ich nichts finden, dass dort das Problem gefixt sein soll.
(http://www-10.lotus.com/ldd/fixlist.nsf/Public?OpenView&Start=1&Count=30&Expand=2#2)
Würde mich interessieren, weil der IBM Support mir jetzt noch einen HF geschickt hat, der nicht das Problem löst, aber die Debugging-Möglichkeiten erweitert (durch 2 neue notes.ini-Einträge). Ich soll das Problem jetzt reproduzieren (was mir im Moment nicht einmal gelingt) und dann die entsprechenden Einträge im Log zusenden.
Wenn es doch gefixt sein soll, warum noch der Aufwand seitens IBM mit Hotfix etc.?
-
Hallo Leute,
das geschilderte Problem hate ich vor kurzem auch .. hatte aber nichts mit meinem Recent Contacts oder den hier beschriebenen Ansätzen zu tun gehabt.
Ich wurde durch einen Admin einfach aus der admin4.nsf entfernt !
Da hilfts dann auch nix, wenn du im Server Dokument sauber eingetragen bist.
Beste Grüße
-
Anfang diesen Monats hat Thomas Bahn seine Lsg. in seinem Blog beschrieben.
> Quick-Tipp: Fehler beim Signieren von Datenbanken mit der Server-ID (http://www.assono.de/blog/d6plinks/Quick-Tipp-Fehler-beim-Signieren-von-Datenbanken-mit-der-Server-ID)
Das war mal wieder ein ganz mysteriöser Fehler: Im Domino Administrator unter dem Reiter Dateien eine Datenbank ausgewählt, im Rechtsklick-Kontextmenü "Signieren..." und im folgenden Dialog "ID des aktiven Servers" gewählt. Sofort kommt eine Dialogbox mit der Fehlermeldung "Sie sind zur Durchführung dieser Operation nicht berechtigt." (You are not authorized to perform that operation).
-
... ich grabe diesen Uralt-Thread nochmal aus ...
Das gleiche Problem trat hier gerade wieder auf einem Client mit Version 9.0.1 FP8 auf.
Ich selbst stand -warum auch immer- im persönlichen Adressbuch drin. Nach dem Löschen dieses Eintrags funktionierte es wieder.
Gruß
Wolfgang