For those who really need a temporary workaround until this is fixed, you can update the path by doing the following:

1. Set the "Notes path" to the desired value (e.g., Path/To/My/Folder).
   • I recommend typing the path in a text editor, copying it, emptying the field, then pasting your value.
2. Quickly, before the above path automatically gets reset, set "File extensions" to a different value.
3. Refresh the page.
4. Open the notes settings again, but this time, set "File extensions" to your desired value (by default, .md).

This works because, upon modifying the value of "File extensions", Nextcloud Notes will send a request to the server to update all the settings to whichever values you set.

Can confirm the workaround from @Benjamint22 has worked for me.
Will there possiby just be an apply-button next to the field or anything else?
I personally find it hard to guess what or when something is happening, when there is a textfield without some kind of confirmation.
But other than that I am really loving the app. 🙏

Also confirm that the work-around from @Benjamint22 worked perfectly!

By the way, as a little bit of input for whomever will review this, prior to trying the work-around, I had tried to make changes via OCC commands (instead of via web gui)...and even THAT failed to work...But its failure was interesting ...Here's what I mean...

I ran the following via the command line in order to make the desired changes to defaults for the Notes app:

sudo -u www-data php /wherever...occ...lives/occ config:app:set notes noteMode --value="preview"
sudo -u www-data php /wherever...occ...lives/occ config:app:set notes fileSuffix --value=".md"
sudo -u www-data php /wherever...occ...lives/occ config:app:set notes defaultFolder --value="my-preferred-folder"

I received "success" sorts of responses. So, then I ran the following command to see what values were actually saved under the Notes' app's config - just you know in case, to verify things:

sudo -u www-data php /wherever...occ...lives/occ config:list notes

Well, the output showed that that my adjustments via the OCC were in fact saved/preserved, and shown in a json format! Meaning that somehow OCC reports that my new desired values are saved...but, the Notes app still did not "see" the new/adjusted values...So, maybe a misconnect between some OCC config and whatever config store the Notes app actually uses?

I would guess the good work-around communicated by @Benjamint22 seems to bypass this bug between OCC and the Notes app's config store...i assume...since the work-around worked for me.

Hoping this minor clue helps any of the Devs in their investigation!
By the way, THANK YOU to all the Devs, maintainers, etc. for all the good work that you all do for this Notes app!!!!!! I love it!

Maybe an interesting information to the devs:
when you click the textbox, the javascript's console gives a 404 while trying to fetch
/apps/notes/js/notes-commons.js
My guess is that the correct path should be
/custom_apps/notes/js/notes-commons.js

Indeed, the notes-main.js try to fetch notes notes-common.js at "apps/notes" even though it is installed in "custom_apps/notes" in my case.

The other .js files doesn't seem to be a problem as their importation is made directly from the requested page, their resolution point correctly to "custom_apps".
But notes-common.js is fetched from within the notes-main.js.

Wouldn’t the problem then come from the build step? resolving the path wrongly ?

I think a way to reproduce this error is to:

1. first uninstall "Notes" if present:
2. edit the config.php in such a way that the "apps" directory isn't writable and give another directory. So setting "apps_paths" to something like that :

  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 => 
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),

and create the directory:
"/var/www/html/custom_apps"

3. first install "Notes"

I was able to fix this issue by adding the next line to the router.js

__webpack_public_path__ = getAppRootUrl("notes") + '/js/';

Don't know if it's a real solution or just a hack. See webpack documentation about it

Just saw the line__webpack_public_path__ = OC.linkTo('notes', 'js/') // eslint-disable-line
in dashboard.js

@OrIOg Indeed. That seems right (of several variations that should work similarly).

Thanks for looking into this you all. :) I do believe this has since been fixed in the main (dev) branch via 582414f as part of some other work.

Manual backport pending in #1341. Can you test that variation in your environment to make sure it behaves as you'd expect to address this issue?

@joshtrichards

I tested the fix using the branch "stable4.10" on Nextcloud(AIO): 29.0.2.2 with Firefox128.0.3 (64-bit),
and the issue about the script path being wrong is corrected.

We can now change the path.

Although another problem appear, if the used note path doesn't contain the forward-slash at the start so the FilePicker can't load the current selected folder.

It seems to be easily fixed this line:

event.target.value === '' ? '/' : `/${event.target.value}`, // path

or something equivalent.

Should I create a new issue or make pull-request to fix this referencing this issue ?

Either fine, but PR preferred. :-)