Version: Unraid 7.2.4

Description:

When deleting a User Share via the Unraid web UI, the share is removed from the UI share list but the corresponding .cfg file is not removed from /boot/config/shares/. Samba continues to read this orphaned config on reload and attempts to serve the share, even though the underlying path no longer exists.

Steps to reproduce:

1. Create a User Share

2. Delete it via Settings → Shares in the web UI

3. Check /boot/config/shares/ — the .cfg file remains

4. Samba begins spamming syslog with canonicalize_connect_path failed for service <sharename> errors

5. Windows clients that previously had the share mapped continue attempting to reconnect in the background, feeding the spam loop

6. After extended time (in my case ~2 weeks of continuous spam), Samba became unstable and crashed, taking nginx/emhttp down with it — requiring a manual nginx command to recover the web UI
   

How it manifested:

The issue went completely unnoticed until the Unraid web UI crashed overnight. There were no alerts, no visible warnings in the UI — the only indication was syslog spam that most users would never see in normal operation. Reviewing the logs afterward showed the canonicalize_connect_path errors had been occurring intermittently for over two weeks before Samba finally became unstable enough to crash and take nginx/emhttp down with it. The web UI required a manual nginx command from an SSH session to recover.

Fix:

bash

rm /boot/config/shares/<sharename>.cfg
/etc/rc.d/rc.samba restart

Note that a reboot does not resolve the issue — Samba re-reads the orphaned config file on every start, so the spam and instability will return.

After removing the orphaned config and restarting Samba, the share no longer appears in Windows Network, which should eliminate the background reconnection attempts that were feeding the spam loop in the first place. A reboot does not resolve the issue — Samba re-reads the orphaned config file on every start, so the spam and instability will return without manually removing the .cfg.

Question for the devs: Should deleting a share via the UI automatically remove the corresponding .cfg from /boot/config/shares/ and trigger a Samba reload? It seems like the UI delete operation is incomplete if the share config persists on the boot drive.

kingslanding-diagnostics-20260408-0853.zip

According to many diagnostics I have examined, many users have lots of these 'orphaned' share .cfg files and probably have had for a long time. Haven't noticed these particular errors in their logs though.

For example:

https://forums.unraid.net/topic/198151-unraid-share-sub-directory-not-showing-contents-on-disks-include-in-share/#findComment-1616929

Not claiming it doesn't happen perhaps in combination with other things in your setup, but it doesn't seem to be common.

Looks like this might be the result of your go file.

Can you reproduce with the stock go file?

Or maybe something you are doing with these "unknown" plugins (I know what they are)

NerdTools.plg - 2024.02.17  (Unknown to Community Applications)
un-get.plg - 2024.11.22  (Unknown to Community Applications)

20 minutes ago, trurl said:

your go file

go file is not the recommended way to do these things anyway.

Unassigned Devices plugin will mount remote shares. User Scripts plugin is where you should be putting other startup code.

See if you can reproduce in SAFE mode.

Thanks for the feedback — a few clarifications though:

Regarding User Scripts as the place for startup code: Available scheduling options, "At Startup of Array" exists, there's no true "at boot" option, only "At First Array Start Only" or array-dependent triggers. My use case requires remote mounts to be available before the array starts, not after. The go file remains the only reliable mechanism for that timing (that i know of).

As for the remote mount setup, it's not just about mounting shares. Remote mounts serves as centralized config storage for multiple Unraid servers. Managing that per-server via Unassigned Devices would be significantly more painful and is not a substitute for what the go file is doing here.

On the Samba connection: the syslog shows the system had been running for over a month before the crash. The go file runs once at boot and doesn't touch Samba share configs at any point after that. The errors are clearly tied to the Citadel share name in /boot/config/shares/ — a path that only gets written when a User Share is created or deleted via the UI. I don't see a credible path from the go file to that orphaned .cfg.

User shares are simply the combined top level folders on array and pools.

If a top level folder is created on array or pools, it is automatically part of a user share named for the folder.

If a top level folder on array or pools doesn't exist, it isn't a user share, even though there may be a .cfg file in config/shares.

If an array disks is unmountable, for example, and it was the only place that had a top level folder for a user share, the user share doesn't exist. If check filesystem fixes the filesystem so the folder exists again, its .cfg file applies to the share again.

So the webUI isn't the only way to create (or delete) user shares.

That's a really helpful clarification on how Unraid defines user shares, and it makes sense. If the underlying folder doesn't exist, the share doesn't exist from Unraid's perspective regardless of what's in config/shares.

To be clear about my specific scenario though, this was not a filesystem issue. There was no failed disk, no corrupted folder, no unexpected disappearance. I created a user share via the web UI, then later deleted it via the web UI. The filesystem is correct. The folder is gone. The share is gone as far as Unraid is concerned. But the .cfg file remained in /boot/config/shares/, and Windows Explorer was still showing the share as visible on the network after the deletion.

The syslog confirms this is a Samba issue, not a filesystem issue. The errors are canonicalize_connect_path failures inside smbd, Samba trying and failing to resolve a path it was told to serve. The filesystem itself was fine throughout.

I resolved it by manually deleting the .cfg file for that specific share, after which the share disappeared from Windows Explorer and the syslog errors stopped. Whether the .cfg file being present was the direct cause of Samba's behavior or a contributing factor, that seems worth looking into, particularly given that the errors persisted long enough to eventually destabilize Samba and take nginx down with it.

Happy to provide any additional diagnostics that would help narrow it down.

3 hours ago, trurl said:

See if you can reproduce in SAFE mode.

4 hours ago, wesman said:

My use case requires remote mounts to be available before the array starts

Why?

On 4/8/2026 at 3:50 PM, trurl said:

Why?

does there need to be a reason?

Just wondering if there was an alternative to trying to do things before the array starts.

On 4/8/2026 at 12:44 PM, trurl said:

See if you can reproduce in SAFE mode.