Create a ticket

Q100146: Nuke license denied when a license should be available


You have a mix of Nuke, NukeX, and/or Nuke Studio floating licenses and you are monitoring the use of the licenses being checked out from the license server. Sometimes a user tries to run one of the products and is denied with a message that all of the licenses are in use, but you believe that a license should be available. What should you check?


You should know how Nuke products take licenses. You should be aware of the effect of mixing Collective (i.e. token) licenses and regular licenses. And you should see what licenses are in the server’s pool of available and in-use licenses.

The Nuke/NukeX/Nuke Studio suite consumes 1, 2, or 3 licenses - depending on which mode you launch:

Nuke requires one nuke_i.
NukeX requires one nuke_i and one nukex_i
Nuke Studio requires one nuke_i and one nukex_i and one nukestudio_i

A single collective license offers a wider set of products to run, but once a machine has taken a product license from the collective set, then the whole set is virtually reserved for that client and that client can use them all. No other client can use a product license from the collective until all of the product licenses in that single collective set are no longer in use. If you have 2 collective licenses, then 2 machines can have a set, but the reservation rule still applies. A collective license starts with one block containing “foundry_production_i" followed by product licenses containing “token_locked”.

Given 1 and 2 above, it is possible, and generally advisable, to construct your license server’s floating license file with the collectives at the bottom and the regular Nuke licenses above them. This is so that someone taking a nuke_i doesn't tie up a collective mari_i or modo_i when there were regular Nuke licenses available separately. The other thing to realize is that if your users are pulling, in sequence, a variation of NukeX and Nuke and Nuke Studio, then the product will hunt for the first unallocated license. If my only nukestudio_i is in a collective, I might pull a nuke_i and a nukex_i from regular licenses above it in the file, but I'll tie up another nuke_i and nukex_i simply because my license manager had to allocate the nukestudio_i out of the collective - which contains all 3 product licenses.

You see what licenses are in the server’s pool and who has them by running a FLU diagnostic and looking at the section following the word “pool”. You can also find the server’s event log “foundry.lic” inside the diagnostic, and there it will tell you when it read the license file and which license file it read. To get the FLU diagnostic:

Launch the Foundry License Utility (FLU), which is here:

on Mac:

on Linux:

on Windows:
(on Windows, launch the FLU by right-clicking on it and selecting "run as administrator".)
C:\Program Files\The Foundry\LicensingTools7.x\
C:\Program Files (x86)\The Foundry\LicensingTools7.x\

On the FLU:
click on "Diagnostics" then
"Run Diagnostics" then
"Save" the output as a file or read it directly from the FLU window by scrolling down.


Was this article helpful?

We're sorry to hear that!

Please tell us why.
0 out of 2 found this helpful