I can't see how this has anything to do with NeDB. I would suggest asking within the Electron community how others are already handling this today.

try changing the permissions on the file

fs.chmod(fileName, 0666, (error) => {
  console.log('Changed file permissions');
});

another way is to make sure you run the app as admin or with sudo. gl`

Initially incorrect file access rights should be fixed manually.
Proposed pull request adds NeDB control of file access mode.

Indeed hard for me to see this as relating to NeDB given this is a file permission issue, likely due to config switch between Electron versions.

Also not sure I see value in having NeDB manage datafile permissions vs simply the developer?

It is insecure to manipulate file access righs AFTER creation and writing file contents.
Access righs should be set BEFORE creating a file or any attacker could listen to FS changes and to open a file before access righs were "fixed".

NeDB uses default NodeJS methods fs.open and fs.writeFile and asynchronous operation.
All these disallows me (as a developer and as an OS administrator) to control over file mode of NeDB files.
I want more secure files to be created with mode 600 and less secure file to be created with mode 640/660.
But you're simply arguing that NeDB shouldn't manage datafile permissions.
Why?
Why OS call to "open" makes this possible and you're revoking these righs from me?

$ umask
0000
$ node aa.js ; ls -l aa.nedb
-rw-rw-rw-. 1 xx xx 0 Mar 26 22:42 aa.nedb

const NeDB = require('nedb')
const fs = require('fs')
const msk = process.umask(0o060);
// enable autoload for the file to be created almost immediately
const db = new NeDB({filename: 'aa.nedb', autoload: true});
process.umask(msk);

Just refer to my pull request #549 which makes possible to specify file access mode and pass it to fs.open and fs.writeFile functions making file manipulation more secure and controllable way.

I saw the PR indeed but I still do not think permissions should be managed by NeDB - if you are worried about security to the point of wanting to mitigate the possibility of an attacker listening to FS changes I'm not sure NeDB is the right choice. Not that it has vulnerabilities that I know of, but given the intended usecase I did not put extra care on security.

Nice to hear from you that you're not worrying about security.
Each your internal call to "crashSafeWriteFile" would reset my permissions set on target file to insecure.
Anyway, without modification of NeDB I'm ABSOLUTELY unable to control over file permissions, because NeDB overwrite it asynchronously without any notification/callback.

The simpliest way to properly handle file permissions is to pass it to NodeJS file operations via NeDB constructor.
Otherwise it is unsolvable.