The Parent property of X is locked, current parent: NULL

What the message means

ServerScriptService.Effects:18: The Parent property of Spark is locked, current parent: NULL, new parent Workspace

Other forms of the same message:

• The Parent property of Sword is locked, current parent: NULL, new parent Backpack
• The Parent property of Bullet is locked, current parent: NULL, new parent Workspace

NULL is the engine's word for nil. current parent: NULL plus a locked Parent means the object was destroyed; the last part names where your code tried to put it.

A destroyed object still exists in your variable, and you can still read its Name, which is why the mistake is easy to miss. It just can never go back into the game. Setting Parent = nil yourself, without Destroy, does not lock anything.

Causes and fixes

Three things cause this error in practice. Each one below has the smallest code that triggers it, then the fix.

• The same object is used again after Destroy
• Debris destroyed an object you kept
• A tool or part of an old character is reused

The same object is used again after Destroy

An effect, bullet or pop-up kept in one variable and shown again on every use works the first time. The second time, the copy from last time has been destroyed.

local ReplicatedStorage = game:GetService("ReplicatedStorage")

local spark = (ReplicatedStorage:WaitForChild("Spark") :: BasePart):Clone()

local function playSpark(position: Vector3)
	spark.Position = position
	-- second call: The Parent property of Spark is locked, current parent: NULL
	spark.Parent = workspace
	task.wait(0.5)
	spark:Destroy()
end

playSpark(Vector3.new(0, 5, 0))
playSpark(Vector3.new(4, 5, 0))

Keep the original as a template that is never destroyed, and clone it inside the function, so every use gets its own copy.

local ReplicatedStorage = game:GetService("ReplicatedStorage")

local template = ReplicatedStorage:WaitForChild("Spark") :: BasePart

local function playSpark(position: Vector3)
	local spark = template:Clone()
	spark.Position = position
	spark.Parent = workspace
	task.delay(0.5, function()
		spark:Destroy()
	end)
end

playSpark(Vector3.new(0, 5, 0))
playSpark(Vector3.new(4, 5, 0))

Debris destroyed an object you kept

Debris:AddItem(object, seconds) destroys the object when the time is up, even if your code has put it back in a pool to reuse. The next time the pool hands it out, it is already destroyed.

local Debris = game:GetService("Debris")

local pool: { Part } = {}

local function getBullet(): Part
	return table.remove(pool) or Instance.new("Part")
end

local function fire()
	local bullet = getBullet()
	-- after Debris ran: The Parent property of Part is locked, current parent: NULL
	bullet.Parent = workspace
	Debris:AddItem(bullet, 2)
	task.wait(1)
	bullet.Parent = nil
	table.insert(pool, bullet) -- still destroyed one second later
end

fire()
task.wait(3)
fire()

Pick one: either pool objects and never destroy them (hide them with Parent = nil), or destroy them and never reuse them. Do not mix a pool with Debris.

local pool: { Part } = {}

local function getBullet(): Part
	return table.remove(pool) or Instance.new("Part")
end

local function release(bullet: Part)
	bullet.Parent = nil -- hidden, not destroyed, so it can be used again
	table.insert(pool, bullet)
end

local function fire()
	local bullet = getBullet()
	bullet.Parent = workspace
	task.delay(1, release, bullet)
end

fire()
task.wait(3)
fire()

A tool or part of an old character is reused

When Workspace.PlayerCharacterDestroyBehavior is set to Enabled, Roblox calls Destroy() on a player's old character when it is replaced on respawn, so everything inside it is destroyed too, including a tool the player was holding. A script that kept a reference to that tool and parents it again after the respawn fails.

local Players = game:GetService("Players")

Players.PlayerAdded:Connect(function(player)
	local character = player.Character or player.CharacterAdded:Wait()
	local sword = character:WaitForChild("Sword")

	player.CharacterAdded:Connect(function()
		-- the old character (and this sword) was removed on respawn
		sword.Parent = player:WaitForChild("Backpack")
	end)
end)

Do not carry objects across respawns. Give a fresh copy from a template in ServerStorage each time the character spawns, or put the tool in StarterPack and let Roblox hand one out.

local Players = game:GetService("Players")
local ServerStorage = game:GetService("ServerStorage")

local swordTemplate = ServerStorage:WaitForChild("Sword") :: Tool

Players.PlayerAdded:Connect(function(player: Player)
	player.CharacterAdded:Connect(function()
		local backpack = player:WaitForChild("Backpack")
		swordTemplate:Clone().Parent = backpack
	end)
end)

How to find the line that causes it

1. Open Output (Window menu, or the Script tab), clear it with Ctrl+K (⌘K on Mac), and press Play.
2. Find the first red line. It starts with the script's place in the Explorer and the line number, such as ServerScriptService.Shop:12:.
3. Click the red line. Studio opens that script with the cursor on the failing line.
4. Read the lines between Stack Begin and Stack End under it: they list the calls that led there, newest first, so you can see which function called the broken one.
5. Still not sure which value is wrong? Add print(typeof(x), x) just above the line, or set a breakpoint on it and read the values in the Watch window.

Questions

Sources and further reading

• Roblox Creator Docs: Instance:Destroy. sets Parent to nil and locks it; a destroyed instance cannot be reused
• Roblox Creator Docs: Debris
• Roblox Creator Docs: Instance:Clone

How the code was checked: every block marked Fixed passes Luau's strict type checker against Roblox's API definitions (luau-lsp, 4 November 2026), and every block marked Breaks compiles and fails only when it runs. The message wording was checked against the message format string in Roblox Studio itself (macOS build installed on 24 October 2026) on 4 November 2026. What Destroy does to the Parent property is from the Instance reference in the Roblox creator docs. A type check catches misspelt APIs and wrong types, not game logic, so playtest in Studio before you publish.