New article published and a Domino 6 bug uncovered
Late last night I hit the publish button on the latest article. As ever, I was working on my home server, EPSDOMSVR01. The site you look at now is a replica on domino-99.codestore.net. The normal process is press publish and replicate between the servers. Not last night though. When I tried to replicate one way I got this error:
Are they joking? It's stacked on top of it! Before I got too worked up I switched icons and tried to replicate the other way. This is what I saw:
Now they really are having a laugh. I'm the bloody manager. I'll do as I please. Although in this case I was resigned to copying and pasting the new article over, going to bed and worrying about what the problem was this morning. Now, brace yourself for this one. It was because Anonymous, yes Anonymous, did not have the ACL option "Replicate or copy documents" enabled. What the?
Thinking back, I do remember disabling this property for Anonymous about a week ago. Why? Because I really didn't think you guys needed it. But no, you, my anonymous web friends, have to have the ability to replicate and copy my documents...
Skip to the 
You can subscribe to an individual
Jake
I've been having exactly the same problems with my R6 server but I have noticed that the problem comes and goes. One minute I can replicate fine, the next minute I get the errors you got. Then a few minutes later it works again. We just tried changing the Anonymous ACL setting here as you suggested and it doesn't seem to have helped though?
Update. Jake, the ACL change may have had an effect after all. Replication now seems to work. If that's fixed it for us, thanks for pointing it out!
Simple answer - don't use the client. Type "rep server path/db.nsf" at one or other server console - the servers assuming set up properly can do what they like. Its also faster and keeps all of the processing off the client.
My colleague had the exact same problem this morning, he found that by removing both of the stacked icons from his workspace and then re-adding them again solved the problem!?
Very weird indeed.
Jake, which release of ND6 are you running?
Tom. Don't know about Jake but we have this problem and we have Server at 6.02. Clients at 6.01.
Tom - All of them ;-) My client is 6.0.1. One server is 6.0.2cf1 and the other is 6.0....
Jake is this a 6.0.2 CF1 server? If so, I stared getting the same thing on my new server I installed last weekend. I simply kicked it a few times and it then let me in. I.e. I had to manually double click the icon to open the database and then replicate and it was fine. In other words it's very intermittent. This is my first 6.0.2 CF1 server and the first time I have had these issues (ever) so the two might be related?
Mike. One of them is. I tried all the usual things before searching the forums. Removing icons. Opening database. Resstarting client. Nothing. The only thing that worked was to give Anonymous replication rights.
Don't you just love Notes...
had the same problem with my ddn account. i'd make changes to my db, or add a document or whatever, and sometimes i could replicate, sometimes i couldn't. seemed like if i screwed around with the acl randomly, it would work once. and then stop working. and then work some more, sort of. and then quit.
until justin knol pointed out somewhere on his blog that every single entry in the acl of the db has to be allowed to replicate. which of course is retarded, why have the option there in the first place?
obviously this "feature" wasn't ready for the light of day. it'd be nice if they get that fixed, it would really be great to be able to lock down replication like that.
I'm working with Domino 6.02 and a client 6.01. I replicate from my client as wells as from the server console. I have the same issue you and others are experiencing. I'll change the acl to allow Anonymous to replicate. But I definitely have to disagree with Jim G. The problem occurs whether you use the console or icon to icon.
Giving it a serious look, you'll see that notes are stamped with $KeepPrivate="1" when replication/copying is disabled for any user who's accessed the database. NOT the way I'd have done it. Prevents not only copying/replicating, but printing from the client as well.
Pity -- it's a feature I would like to have used, since I have a number of applications that need to be on the server, interacting with their chums, in order to work properly. Checking an option in the ACL is a lot easier than throwing server-name checks in all over the design....
@Jonvon & Jake - I could kiss you guys I really could! I've been having this problem with my DDN account for months and no end of support calls could solve it until this little gem of a blog gets written. Its now working as it should - you beauty!!!
This has happened to me a couple of times on 6.01CF1. My application has a whole host of groups etc, including Default which do not have the "replicate or copy documents" set. In my case, it is with a new database not yet in production, so I deleted and recreated the replica, and then it works fine for a while. However, it's due to go into production shortly, so I will update the ACL to prevent this problem in the future, as it was also affecting clustering replication.
Thanks...
For the record - If you're having problems with this, it's not the case that you need to add Anonymous. Just make sure that ALL entries already in the ACL have Replicate rights. That should fix it.
Add me to the list of the grateful. This problem had been tormenting me for months. I now officially have 7 hairs left on my head. But with this minor ACL tweak, as of last night I replicate fine every time, and my scalp again has a fighting chance! Thanks gents.
anyone have an SPR# so I can get this fixed?
I wrote this up as a PBR on Sept. 17, Ed. The problem is actually caused by two things: 1) having the Replicate or Copy Documents property turned off on anonymous, and 2) the HTTP task having recently accessed the database. It appears that the HTTP task gets an exclusive lock to the db, and won't allow other tasks, such as replication, to access the db. That is why it is intermittent - if the HTTP task hasn't touched the db, then you won't get the problem.
Lotus has acknowledged the problem (Gloria, for those of you in the BP Forum). I'll come back and let you know when the status is updated.
Rock
Thanks for the solution Jake - you're a star!
This problem actually stopped us from rolling out R6 to our Extranet and Internet websites. Lotus support had no answers.
Great to finally have this one solved.
Another situation that does not involve the HTTP stack issue is a database with -Default- not having the "Replicate..." option checked. Especially when operating on a local database (acl). Temporarily remove the -Default- ACL entry do your rep'ing then use GrantAccess to recreate it. Note - you cannot use Revoke Access to remove it - that is for COM only.
Oy Vey!