This issue has been around for a long time from what I can tell, I’ve only just dug into the source to see what’s going on to report it.
What my game does is keep building interiors in ReplicatedStorage, then let the client grab them and move them into Workspace when it needs to use them. In some cases, these building interiors have sounds in them that the server is able to trigger upon request.
The problem I’m running into is that, while the server is successfully able to change any property of Sound objects in ReplicatedStorage, the Playing, TimePosition, Play(), Pause(), Stop(), and Resume() properties and functions do not replicate to the client while all other properties replicate successfully. The end result being the server sees the sound as playing, but the client does not see the sound playing and the player is left without sound for the action they triggered.
If you poke around in an F7 test session of this repro, you can see a Sound parented to a Part under ReplicatedStorage. A script in StarterPlayerScripts grabs that part and moves it into Workspace when the game starts, and 10 seconds later the server enables the Sound object, which it still thinks is in ReplicatedStorage. You should be able to see that the server sees the sound as playing, but the client doesn’t.
Sound replication in general feels kinda janky sometimes, so if this actually isn’t a bug it needs to be documented somewhere.
Edit: read the reply below, AFAIK needs some updating on my part; thanks @TwentyTwoPilots for clarifying
I don’t think this is a bug AFAIK; the server has no idea where the client moved the sound since you can’t expect the client to replicate reparenting of most (if not all) objects. If the sound is misplaced, the sound played on the server will probably try to replicate as being played in replicated storage, which doesn’t work because the client can’t find that sound being in that directory.
As an example, if I have a part in the workspace and I locally parent it to lighting, any server updates regarding that part are likely to be ignored (unless you set the parent again to workspace, I’m not sure at that point if the server would correct the parent after the client messed with it earlier). A server reposition might not be seen visually since it’s still not in the workspace, similar to your sound in that a playing sound in replicated storage isn’t supposed to be heard.
Regardless, this issue is beyond just sounds - if you are tampering things locally, replication will feel janky in most cases. It is safer to use a remote event and tell the client to play the sound, since the client actually knows the whereabouts and current non-replicated properties of the sound that the server wouldn’t know. This would go for any local or locally tampered object.
In the case that it is a bug, I still think using a remote is safer for these kinds of things where the client is treating the objects differently than the server.
That’s not how replication works, as far as the server and client are concerned they are the same exact objects and the server triggering changes to specific properties will be replicated to each client and override what they see. This is basic manipulation of the server / client relationship, and you can see that when you toggle any other property of the sound object or any other property of any other instance. Using RemoteEvents or RemoteFunctions in this instance is a messy workaround to something that’s just supposed to work.