Problem saving settings

[gianni_1]

Hi,
Could someone please tell me why Calibre refuses to save changes to the settings? Could it be due to the latest Windows 11 update?
Thanks, Gianni

calibre, version 9.15.0
ERRORE: Eccezione non gestita: <b>PermissionError</b>:[Errno 13] Permission denied: 'C:\\Users\\sturm\\AppData\\Roaming\\calibre\\conv ersion\\epub_output.py'

calibre 9.15 embedded-python: True
Windows-11-10.0.26300-SP0 Windows ('64bit', 'WindowsPE')
('Windows', '11', '10.0.26300')
Python 3.14.7
Windows: ('11', '10.0.26300', 'SP0', 'Multiprocessor Free')
Interface language: it
EXE path: C:\Program Files\Calibre2\calibre.exe
Successfully initialized third party plugins: Find Duplicates (1, 10, 10) && Job Spy (1, 0, 239) && Manage Series (1, 5, 4)
Traceback (most recent call last):
File "calibre\gui2\preferences\main.py", line 534, in accept
File "calibre\gui2\preferences\main.py", line 495, in commit
File "calibre\gui2\preferences\conversion.py", line 126, in commit
File "calibre\gui2\convert\__init__.py", line 319, in commit
File "calibre\gui2\convert\__init__.py", line 128, in commit_options
File "calibre\ebooks\conversion\config.py", line 27, in save_defaults
PermissionError: [Errno 13] Permission denied: 'C:\\Users\\sturm\\AppData\\Roaming\\calibre\\conv ersion\\epub_output.py'

[JSWolf]

I don't know why you are getting Permission denied, but it's not due t the latest Windows update for Windows 11.

[Jaws]

I very slightly disagree that "it's not due to the latest Windows 11 update" — although it shouldn't be! — because there is one slight change in the latest Feature Update (26H2) that might be causing difficulty. The Preview version of that Feature Update was in the wild around the 26th, a couple days before Gianni reported his problem.

One ill-documented "feature" of 26H2 is that it is slightly more aggressive in screening out accounts whose permission status (mere "user" versus "administrator") has changed since Windows activation, and allegedly even installation of a third-party program in the \user hierarchy from unrestricted write access to parts of the \user that were not installed at that very moment. In both the 24H2 and 25H2 Preview Versions of the Feature Updates, this led to write-permission confusions when that third-party-program's installer (the .msi) calls yet another third-party-program's installation routine doesn't "correctly" identify which user is installing it — and Python doesn't. It wouldn't surprise me one bit if 26H2 is acting the same, or there's a lingering problem from a previous Feature Update.

Notice the scare quotes around "correctly"? It's a side effect of Microsoft's increasingly intrusive attempts to make people install everything via the Microsoft Store (just like the shift for Kindle Reader for Windows in the last few months), and Python… isn't. (Editorial comment: And shouldn't be; this is monopoly-enhancement BS, not anything related to an actual security issue. At least it's not the Apple/Android foofery… at least not yet.)

I understand that this can be fixed by, with the "offending" program running, manually going in to the blocked \user folder and running the "take ownership" on that folder. I haven't had the problem (I don't install Preview Versions of anything, and custom-installed Windows so the "account-status change" thing won't ever be an issue), so I haven't tested it, but Gianni should give this a try. He should also ensure that he's logged in as the same user as he was at Calibre installation, so that the Python files are also installed for that same user — and that that user was an administrator account.

[JSWolf]

I'm running 26H2 and I have no problem.