Help / Troubleshooting
My NAS folder is rejected, or tags will not save over the share
Music on a network share plays perfectly, then the folder will not stay added, or a tag edit fails on a file you can plainly read. Two problems, with different causes.
The short answer
A folder that looks rejected is a reachability or visibility problem, and a banner names which. A tag write that fails on a share you can read is a permission or naming problem: saving a tag asks far more of a share than reading one does.
When the folder will not take
Add the share on the Tools tab with Add Folder, which opens a picker titled Select Music Folder. Either route works: a drive letter you mapped in Windows, or the share's network name. Stick to one, because registering the same music as both Z:\Music and \\nas\music indexes it twice and makes false duplicates.
The share did not answer in time. Before scanning, the app asks the share for its details and gives it three seconds, trying three times in all, half a second apart. A NAS that spins its disks up on demand can miss all three. Wake the share in File Explorer, then press Rescan Library.
The share is genuinely offline. A banner reads Network share unavailable, naming the share, with a Retry button. The tracks are marked offline, never deleted, and play again once the share is back. Library Health lists them under Offline / unreachable tracks, where Reconnect & re-probe restores every folder that answers again.
You are running Vesari Stylus as administrator. Windows ties a mapped drive to the sign-in token that created it, and an elevated app runs under a different one, so Z: is invisible to it. When a drive-letter folder goes unreachable under elevation the app says so on a banner and leaves your tracks alone. Close it and start it normally; a share added by its network name never runs into this.
One path form is refused outright: an extended-length or device path, the kind beginning \\?\ or \\.\. An ordinary \\server\share is fine. Network folders are not watched for changes the way local ones are, so new NAS music appears on the next Rescan Library. See Your NAS and network drives and How scanning works.
Why a tag write fails on a share that reads fine
Saving tags never edits your file in place. The app copies the track to a temporary file in the same folder, writes the tags into that copy, flushes it to disk, then renames the copy over the original. A dropped connection or a power cut therefore cannot leave you with a half rewritten track. It also means a save needs things a read does not:
- Room for a second copy of the file in the same folder while the write runs.
- Permission to create a file in the folder and to replace an existing one. Read and write are separate rights on an SMB share. A share exported for reading only, or one where your PC lands on a guest account, reads and plays flawlessly while refusing both.
- The file must not carry the read-only attribute. The app checks before copying anything and refuses rather than half rewriting the track. Clear the attribute in Windows and save again.
- The file must not be held open. Playing the track holds it, and so can a sync client or another tagger. The failure names this case. Stop playback and try again.
- Path room. The temporary file is the track's own name with a short suffix added, so its path is longer than the one it copies. Windows caps a full path at around 260 characters, which deep NAS trees reach easily. Shorten a folder name and try again.
Failures appear in the tag editor as Save failed with the reason attached, and the editor stays open with your edits intact. The file itself is left alone either way: after a write the app reads the tags straight back and checks title, artist and album against what you typed, and if they do not match it puts the previous tags back and reports the save as failed. A share that accepts a write without keeping it leaves the file as it was.
Names that are legal on the NAS but not on Windows
Linux and Samba allow characters Windows does not: a colon, a question mark, an asterisk, angle brackets, a quote, a pipe, and names ending in a dot or a space. Such a file plays fine, but Windows cannot rename it, so duplicate cleanup can neither move it into quarantine nor put it back. They are skipped whole, with the reason given; rename them on the NAS itself to bring them in.
Files that hold no tags at all
Two cases are not the share's fault. Raw DTS, AC-3 and TrueHD streams have no tag container, so their metadata lives in your library and in a .tags file beside the audio, written best effort. Some WAV files have a container no tag writer can round-trip; those save to the library only, and WAV tags will not save covers them.
If none of this fits, note the exact Save failed message before closing the editor. Is this a bug? How to report it explains what to send.