In a typical multiplayer game, clients are not all authoritative about the outcomes of their actions. They say what they're trying to do, not what the outcome was.
This avoids the classic playground bicker in imaginary play, "I hit you!" "Nuh-uh! You missed!" - if both players are equally authoritative about the outcome, then we can't resolve who's right.
To fix this, we make one party the recognized & trusted authority. In a LAN game, this will generally be the player who first started the game session for others to join - usually denoted the "host". (To make your game code more symmetric & consistent, you can make the host server a separate process that runs on the host player's machine, and both the host player and client players run identical client logic communicating with that server process - either over the LAN or via the localhost/loopback address 127.0.0.1. This will make it easier if you decide to port it to an online multiplayer with a dedicated server in future.)
Clients tell the host/server their actions, and the host tells the clients the results of those actions. Because the events arrive at the host in some order, it can authoritatively dictate which action happened first and succeeded, or which happened second and failed.
So it might go like this:
Client 1 and client 2 simultaneously report "I try to place my carried object at point X"
Client 1's request arrives at the server first, and the server updates the game state to say there is an item at point X, and replies back to client 1 to say their action succeeded. Client 1 sees their placement animation complete normally.
Client 2's request arrives at the server second. The server checks point X, and finds there's already an item there, so it replies back to client 2 "you can't do that - it's occupied". Client 2 sees an animation where the item bounces off of the item client 1 just placed and returns to their hand, so they stay in the carrying state.
Over a LAN, the latencies of these messages will be very short, so you might not need any complicated lag compensation algorithms or fancy animations to cover the delay between action and result, or the cases where the server has to invalidate an action the client thought they could do. As long as your placement action takes more than one frame, you should have time to get an authoritative response back and decide whether to complete the action or interrupt it and roll it back.