@dunlix (and others)

Thanks, the disable plugins suggestion worked. Apparently it was the "sanitize html" plugging that was causing the problem.

Not even sure why we had that still installed.

Thanks all for the troubleshooting help!

@dunlix - This server has been running fine for almost two years through multiple upgrades. The problem didn't occur until applying the latest version (I can confirm no reverse proxy changes).

I eliminated the network as a culprit. Tried to edit from three different PC's on three wildly different networks (i.e. not like my wifi and the neighbor's wifi, but very different networks).

@phenomlab - no browser extensions. I even tested this in a vanilla browser with no plugins.

I did see an error on the backend finally:

Oct 13 08:05:37 www nodebb[10920]: 2021-10-13T08:05:37.630Z [4567/10931] - #033[31merror#033[39m: modules.chats.newRoom
Oct 13 08:05:37 www nodebb[10920]: Error: [[error:no-privileges]]
Oct 13 08:05:37 www nodebb[10920]:     at SocketModules.chats.newRoom (/opt/nodebb/src/socket.io/modules.js:56:9)
Oct 13 08:05:37 www nodebb[10920]:     at runMicrotasks (<anonymous>)
Oct 13 08:05:37 www nodebb[10920]:     at processTicksAndRejections (internal/process/task_queues.js:97:5)
Oct 13 08:05:37 www nodebb[10920]:     at async onMessage (/opt/nodebb/src/socket.io/index.js:164:19)
Oct 13 08:06:14 www nodebb[10920]: 2021-10-13T08:06:14.280Z [4567/10931] - #033[31merror#033[39m: modules.chats.newRoom
Oct 13 08:06:14 www nodebb[10920]: Error: [[error:no-privileges]]
Oct 13 08:06:14 www nodebb[10920]:     at SocketModules.chats.newRoom (/opt/nodebb/src/socket.io/modules.js:56:9)
Oct 13 08:06:14 www nodebb[10920]:     at processTicksAndRejections (internal/process/task_queues.js:97:5)
Oct 13 08:06:14 www nodebb[10920]:     at async onMessage (/opt/nodebb/src/socket.io/index.js:164:19)

@baris - Yes, I see a post to /api/v3/categories..

{name: "Test1234", description: "", icon: "fa-comments", uid: 1747, parentCid: "0", cloneFromCid: "0"}

After a while, it reports a net::ERR_HTTP2_PROTOCOL_ERROR

Also checked the Mongo logs for errors to rule out any backend storage problems. Nothing of note in the logs.

@pitaj - Nothing in either. Server logs going to syslog (running as a daemon). Running "nodebb logs" doesn't seem to show anything either.

Going to stop it and run it manually from the command line. Nope.. nothing there either. Command just goes off into the sunset and does nothing. Clarification: There is logging showing up, but nothing that looks like an error around the second or so after I hit the "save" button on the new Category.

Browser console shows nothing of interest in either case, also.

I (admin) can go to Manage -> Categories.. If I hit the "+", enter a name, click "Save" - nothing happens. No new Category is created. I've tried creating a top level category and a category as a child of something else and same behavior.

I was running 17.x and was having the issue. I upgraded to 18.4 (I think) - whatever the latest as of the writing of this post. Behavior remained the same.

Any guidance on troubleshooting?

Thanks

I've read this and this and I've validated my config.json url property is correct (that URL, if pasted into a browser properly reverse proxies through Apache to nodebb)

Is there some other setting that could be affecting that?

I've read all the docs and searched the forums several times over, but it's still not clear to me if you can upgrade across branches in one step.

For example, if I'm on 1.10.2, can I upgrade directly to 1.12.2?

In the past, I've always applied each interim release to get from point a to point b (i.e. in this case 1.10.2 -> 1.11.0 -> 1.11.1 -> 1.12.0 -> 1.12.1 -> 1.12.2).

If it's generally agreed that doing it one fell swoop is "no problem" (TM), it would save me some typing and time.

While using less in the custom CSS, is it possible to gain access to the colors used in the theme/skin (specifically the skin).

I'm trying to plop in a background image floating underneath the content but allowing users to change skins causes problems because the main content area is transparent. So either I can set it to something light, which messes up dark skins, or set it to something dark, which messes up light skins.

Ideally, I'd like to transplant the body background color to the #content div without modifying the theme or skins.

Thoughts?

In a fit of desperation, I ran the nodebb upgrade again and it finished with no errors. Should I be worried? (yes, I made a backup so I have a safety net if necessary).

Encountered this error during upgrade (1.9.x -> 1.10.0).

Forums are down, so I don't have access to the admin console. Looks like it's permissions based. Is it safe to delete the offending duplicate (and my command line mongodb kung fu is weak so assistiance would be grealy appreciated).

Updating NodeBB...

1. Updating package.json file with defaults...  OK

2. Bringing base dependencies up to date...  started
npm WARN [email protected] requires a peer of bufferutil@^3.0.2 but none was installed.
npm WARN [email protected] requires a peer of erlpack@hammerandchisel/erlpack but none was installed.
npm WARN [email protected] requires a peer of node-opus@^0.2.6 but none was installed.
npm WARN [email protected] requires a peer of opusscript@^0.0.3 but none was installed.
npm WARN [email protected] requires a peer of sodium@^2.0.1 but none was installed.
npm WARN [email protected] requires a peer of libsodium-wrappers@^0.5.4 but none was installed.
npm WARN [email protected] requires a peer of uws@^0.14.5 but none was installed.

3. Checking installed plugins for updates...  OK
4. Updating NodeBB data store schema...
Parsing upgrade scripts... 
OK | 4 script(s) found, 53 skipped
  → [2017/6/22] Hash all IP addresses stored in Recent IPs zset... OK
  → [2018/5/28] Give global search privileges... OK
  → [2018/6/7] Give post history viewing privilege to registered-users on all categories... OK
  → [2018/6/8] Give deleted post viewing privilege to moderators on all categories...
2018-11-09T16:07:00.294Z [31427] - error: [groups.join] Could not create new hidden group MongoError: E11000 duplicate key error collection: nodebb.objects index: _key_1_value_-1 dup key: { : "group:cid:166:privileges:posts:view_deleted", : null }
    at Function.MongoError.create (/opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/error.js:45:10)
    at toError (/opt/nodebb/node_modules/mongodb/lib/utils.js:149:22)
    at /opt/nodebb/node_modules/mongodb/lib/collection.js:1029:39
    at /opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/connection/pool.js:544:18
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)
Error occurred
Error occurred during upgrade: MongoError: E11000 duplicate key error collection: nodebb.objects index: _key_1_value_-1 dup key: { : "group:cid:166:privileges:posts:view_deleted", : null }
    at Function.MongoError.create (/opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/error.js:45:10)
    at toError (/opt/nodebb/node_modules/mongodb/lib/utils.js:149:22)
    at /opt/nodebb/node_modules/mongodb/lib/collection.js:1029:39
    at /opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/connection/pool.js:544:18
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)

/opt/nodebb/node_modules/mongodb/lib/utils.js:132
      throw err;
      ^
MongoError: E11000 duplicate key error collection: nodebb.objects index: _key_1_value_-1 dup key: { : "group:cid:166:privileges:posts:view_deleted", : null }
    at Function.MongoError.create (/opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/error.js:45:10)
    at toError (/opt/nodebb/node_modules/mongodb/lib/utils.js:149:22)
    at /opt/nodebb/node_modules/mongodb/lib/collection.js:1029:39
    at /opt/nodebb/node_modules/mongodb/node_modules/mongodb-core/lib/connection/pool.js:544:18
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickCallback (internal/process/next_tick.js:104:9)

Thank you, @baris

GitHub issue: https://github.com/julianlam/nodebb-plugin-support-forum/issues/7

Ok. I think I know what's going on.

We're using a plugin called support forum that looks like it hasn't been updated in quite a while. My guess is that it keeps a hard reference to the tid, even if it's moved to another category.

It's only 168 lines of source, but I don't know Node.js or NodeBB architecture enough to make heads or tails of it. Maybe I should put a bounty on it? Not sure how well those kinds of offers are received, though.

@baris said in Moving topic from one Category to another:

db.objects.find({_key: "cid:<cat_A_id>:tids", value: "<moved_topic_id>"});
db.objects.find({_key: "cid:<cat_A_id>:tids:posts", value: "<moved_topic_id>"});
db.objects.find({_key: "cid:<cat_A_id>:tids:votes", value: "<moved_topic_id>"});
db.objects.find({_key: "cid:<cat_A_id>:tids:lastposttime", value: "<moved_topic_id>"});
db.objects.find({_key: "cid:<cat_A_id>:tids:recent_tids", value: "<moved_topic_id>"});

Very odd, and matches some very odd stuff I've seen on other things.

Replacing with the appropriate topic and category ID's doesn't return any values.

MongoDB shell version: 3.2.16
connecting to: nodebb
> db.objects.find({_key: "cid:35:tids", value: "39220"});
> db.objects.find({_key: "cid:35:tids:posts", value: "39220"});
> db.objects.find({_key: "cid:35:tids:votes", value: "39220"});
> db.objects.find({_key: "cid:35:tids:lastposttime", value: "39220"});
> db.objects.find({_key: "cid:35:tids:recent_tids", value: "39220"});
>

Just so I know it's working, here's the category it was moved to:

> db.objects.find({_key: "cid:54:tids", value: "39220"});
{ "_id" : ObjectId("5a610c4e1a911d0fab1a28aa"), "_key" : "cid:54:tids", "value" : "39220", "score" : 1516309669264 }

Me, as an admin, if I go look at the CatA category, it looks completely blank (all posts moved to private CatB). If I create a regular authenticated user and look at CatA, it's completely blank.

However, the creator of the moved_topic can still see a ghost of the topic in CatA.

Is there some per-user server-side caching going on? I can't see a way this could be client side, especially since there have been multiple reports of seeing the snippet of the most recent post change (right side of the topic in the list when it shows the most recent user to post and the first 100 chars or so of the post itself).

yes. My mongo is a little noobish, but I have command line access.

NodeBB 1.7.0

CatA settings: nothing special. registered users can find cat, access cat, access topic, create topic

CatB settings: also nothing special. privileges are assignd to only one group (full privs across the board for that group)

Long story, but here goes.

1. Two categories: one open to registered users (CatA), one restricted to a group (CatB).

2. Occasionally, moderators will move a topic from the open group to the closed group (CatA -> CatB) to discuss it in more detail in a closed session.

3. The original topic shouldn't be visible in CatA anymore (and to most people, it is not) but the original poster of the topic can still see it on the list. He can't click on it (permission denied in the other forum) but can still see the first line or two of the last post in the preview on the right.

I doubt this is a setup issue. Is this some kind of dangling reference bug?

Re: Change all postings for a one user to another user.

I'd also like to know if it's possible to move one users posts to be owned by another (specifically for merging two accounts created by the same user into one user account).