ID 316252 - ZDefocus/Kronos nodes error when rendering with a fresh Cache directory saying "Directory was not successfully created" [LINUX]

Problem summary
ZDefocus/Kronos nodes error when rendering with a fresh Cache directory saying "Directory was not successfully created" [LINUX]

Customer reported version
nuke.11.0v2

Customer reported platform
ubuntu

Steps to reproduce

1) Open the attached script

2) Repath the Read node to footage, and the Write nodes to a local directory 

3) Save the script and close Nuke

4) Create a new directory in your user

5) Open terminal and set the NUKE_TEMP_DIR env to a new directory you created

6) Navigate to /usr/local and run ./Nuke11.0v2/Nuke11.0 -V -F "100-105" -X KronosWrite -x /path/to/script.nk

7) Create a new directory in your user

8) Open terminal and set the NUKE_TEMP_DIR env to a new directory you created

9) Navigate to /usr/local and run ./Nuke11.0v2/Nuke11.0 -V -F "100-105" -X ZDefocusWrite -x /path/to/script.nk

This issue only occurs the first time you use the Cache location

Expected behaviour
For Nuke to render

Actual behaviour
It returned the following error when rendering for ZDefocus:

Writing /mnt/netshare/support/4Pete/temp/008/ZDefocus_0500.exr
[14:38.03] ERROR: ZDefocus1: Directory was not successfully created
Writing /mnt/netshare/support/4Pete/temp/008/ZDefocus_0500.exr took 0.81 seconds
Total render time: 0.81 seconds
ZDefocus1: Directory was not successfully created

And for Kronos:

Writing /shared/temp/zdef_0100.exr
[17:05.15] ERROR: Kronos1: Directory was not successfully created
Writing /shared/temp/zdef_0100.exr took 0.45 seconds
Total render time: 0.45 seconds
Kronos1: Directory was not successfully created

Workaround
Use the same Cache location more than once

Reproduced by support
This problem has been reproduced on:
Nuke 11.0v2 - CentOS 6.8 - regression
Nuke 10.5v6 - CentOS 6.8 - regression

The issue was not reproduced on:
Nuke 11.0v2 - Windows 10
Nuke 11.0v1 - CentOS 6.8
Nuke 10.5v6 - Windows 10
Nuke 10.5v5 - CentOS 6.8

MacOSX gets a different error, so is logged as a separate bug

Earliest version tested
Nuke 10.5v5 - Bug did not occur before this version