"Access Denied" error on Windows Server in "quarto render"

[JoergVanAken]

I have:

• searched the issue tracker for similar issues
• installed the latest version of Quarto CLI
• formatted my issue following the Bug Reports guide

Bug description

I try to run quarto.exe render on a Windows server. Depending on the user rights this leads to an os error 5 "Access denied".

Steps to reproduce

The content of document does not matter. The problem is caused by this python function in quarto's jupyter.py:

def run_server_subprocess(options, status):

   # python executable
   python_exe = sys.executable

   # detached process flags for windows
   flags = 0
   if sys.platform == 'win32':
      python_exe = re.sub('python\\.exe$', 'pythonw.exe', python_exe)
      flags |= 0x00000008  # DETACHED_PROCESS
      flags |= 0x00000200  # CREATE_NEW_PROCESS_GROUP
      flags |= 0x08000000  # CREATE_NO_WINDOW
      flags |= 0x01000000  # CREATE_BREAKAWAY_FROM_JOB

   # forward options via env vars
   os.environ["QUARTO_JUPYTER_OPTIONS"] = json.dumps(options)

   # create subprocess
   subprocess.Popen([python_exe] + sys.argv + ["serve"],
      stdin = subprocess.DEVNULL,
      stdout = subprocess.DEVNULL,
      stderr = subprocess.DEVNULL,
      creationflags = flags,
      close_fds = True,
      start_new_session = True
   )

The flags of subprocess.Popen commands are a problem if the user has no admin rights.

Actual behavior

Crashes with "Access denied".

Expected behavior

Does not crash :-)

I changed the python code so that is does not use any flags and everything works as expected.

Your environment

Microsoft Windows Version 10.0.20348.3932
Quarto Version 1.7.32

Quarto check output

quarto check

Quarto 1.7.32
[>] Checking environment information...
      Quarto cache location: xx\AppData\Local\quarto
[>] Checking versions of quarto binary dependencies...
      Pandoc version 3.6.3: OK
      Dart Sass version 1.85.1: OK
      Deno version 1.46.3: OK
      Typst version 0.13.0: OK
[>] Checking versions of quarto dependencies......OK
[>] Checking Quarto installation......OK
      Version: 1.7.32
      Path: xx\quarto\bin
      CodePage: 1252

[>] Checking tools....................OK
      TinyTeX: (not installed)
      Chromium: (not installed)

[>] Checking LaTeX....................OK
      Tex:  (not detected)

[>] Checking Chrome Headless....................OK
      Using: Chrome found on system
      Path: C:\Program Files\Google\Chrome\Application\chrome.exe
      Source: Windows Registry

[>] Checking basic markdown render....OK

[>] Checking Python 3 installation....OK
      Version: 3.12.10 (Conda)
      Path: xx/python.exe
      Jupyter: 5.7.2
      Kernels: python3

[>] Checking Jupyter engine render....OK

[>] Checking R installation...........(None)

      Unable to locate an installed version of R.
      Install R from https://cloud.r-project.org/

[cscheid]

Thanks for the report! We first need to understand why those flags are there in the first place.

[cderv]

The problem is caused by this python function in quarto's jupyter.py:

This would mean you can run the render without using a daemon server.

quarto render --no-execute-daemon

This shouldn't call run_server_subprocess() and just execute the notebook in One shot mode.
More on that at https://quarto.org/docs/computations/python.html#kernel-daemon

This could be a workaround in the meantime.

[JoergVanAken]

You are right, this is a workaround - just checked it. This is much cleaner than changing the jupyter.py manually.

[cderv]

Great thanks for confirming. As you will read in the doc, you can also set execute.daemon config to false to set this behavior for a whole project or set of document.

I changed the python code so that is does not use any flags and everything works as expected.

Out of curiosity, did you manage to isolate whether one of them or all of them is responsible?
Did you try remove or set one by one ? Some tedious work, but would be very helpful to understand what creates the issues

We first need to understand why those flags are there in the first place.

I was curious so here is the doc: https://learn.microsoft.com/en-us/windows/win32/procthread/process-creation-flags

Some of the flags used may require some specific privileges that may be restricted by Group policies on Windows server (usually IT-managed or some sort). I am not convinced this requires Admin right, as running on a windows machine does not really trigger UAC currently, but I can't see that a default user may not have the right group policies.

Is the windows server managed by globally by IT orgnization ? Do you know if they set group policies ?

Anyhow, it seems some of the flags are redundant:

• CREATE_NO_WINDOW says "This flag is ignored if the application is not a console application, or if it is used with either CREATE_NEW_CONSOLE or DETACHED_PROCESS."
• So setting DETACHED_PROCESS may be enough.
• CREATE_BREAKAWAY_FROM_JOB seems important to make sure the daemon server is not associated with the deno or python process that would be run at quarto render, as the aim is to have a daemon process staying open in the background. It was added in f9ff262 to make the daemon work it seems.
• CREATE_NEW_PROCESS_GROUP seems to have similar purpose to isolate the process from the process group of python process that would start it. At least, this is how I understand it.

I would say one of those last two can be restricted on your server. I don't know if they are required but I remember that at the early days of Quarto, using daemon server on windows was not working, and so the default was daemon: false until it was solved. I need to dig more in commit history to see if this is relevant.

Hope this helps - at least it will for me to have some notes for later :)

[JoergVanAken]

It took me a few hours to find out that it was due to the flags, which I didn't have in mind at first. That's why I was glad to have found a solution, even if it's not ‘minimal’.

I'm about to go on holiday, but will look into it when I get back.

Thanks for your quick help - great!

[cderv]

It took me a few hours to find out that it was due to the flags, which I didn't have in mind at first. That's why I was glad to have found a solution, even if it's not ‘minimal’.

Yes thank you for that. We would have add a really hard time finding that too. We really appreciate the time you took to open such a precise issue for us to consider a fix. Thank you again!

Have nice holidays