wesman

does there need to be a reason?

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.

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.

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: Create a User Share Delete it via Settings → Shares in the web UI Check /boot/config/shares/ — the .cfg file remains Samba begins spamming syslog with canonicalize_connect_path failed for service <sharename> errors Windows clients that previously had the share mapped continue attempting to reconnect in the background, feeding the spam loop 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 restartNote 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

seems solved, been running for a few hours now. MEMTEST86 Identified a bad ram stick. removed and we are now moving along wit zero errors

Right, thanks.. Update for the thread — we've had two more crashes since the original post and have done a lot more digging. New diagnostics are attached from the third crash this morning. Mirror to Flash was enabled so we have the pre-crash syslog. We also have mcelog output now which gives us something more specific to work with: CPU 5, Bank 0, Internal parity error, Uncorrected error, Processor context corrupt. STATUS b200000000030005. Interwebs say Bank 0 is the CPU's internal logic rather than a DIMM directly. Ruled out a few things. Swapped the PSU to a Dark Power Pro 12 1200W and it crashed again. Temps are completely clean — CPU cores were sitting at 31-34°C under full transfer load with no thermal warnings anywhere in the logs. XMP is disabled and we confirmed via dmidecode that all four DIMMs are running at stock 2133 MT/s. What's interesting is the crashes are escalating. First crash was 5-6 hours in. Second was about 2 hours in. Third was only 28 minutes in. The system is completely stable at idle — this only happens under sustained heavy load. Running memtest86+ now and will report back with results. Main question is: whether a Bank 0 internal parity error on the CPU points toward a failing RAM stick stressing the memory controller, or whether it's more likely the CPU itself degrading. Any guidance there would be appreciated. kingslanding-diagnostics-20260224-1042.zip

Why would it "reboot by itself" ? I mean, why would it ever do such a thing?

Captured the crash again, and this time had "Mirror to Flash" setm diagnostics attachedkingslanding-diagnostics-20260224-0723.zip

Hi all, hoping to get some help diagnosing an unexpected reboot on my server. System: - Unraid 7.2.3, kernel 6.12.54 - ASUS ROG MAXIMUS XI HERO (Z390) - Intel i9-9900K - Three ZFS pools: fleabottom (8x14TB RAIDZ1), greensight (10x12TB RAIDZ2), maester (2x2TB NVMe mirror) What I was doing: Running a large data transfer (~58TB total) from a NAS Pro 8 over 10GbE using parallel rsync workers in screen sessions. The transfer was writing directly to the fleabottom ZFS pool, bypassing shfs. Transfer was running well at sustained 600-700 MB/s for several hours. What happened: Approximately 5-6 hours into the transfer, the server rebooted unexpectedly. No manual intervention. After reboot all three ZFS pools came back ONLINE with no errors. The rsync workers were lost and the transfer had to be restarted, but rsync resumed from where it left off. What I've checked: - All pools show ONLINE with zero READ/WRITE/CKSUM errors after reboot - No kernel panic message visible in syslog (log cuts off before the crash as expected) - System is stable after reboot Questions: 1. What's the best way to capture pre-crash data on Unraid 7 if it happens again? 2. Has anyone seen unexpected reboots during sustained heavy ZFS writes on 7.2.3? 3. Any recommended diagnostic steps for tracking down the root cause? Diagnostics attached. Thanks in advance. kingslanding-diagnostics-20260223-2148.zip

Did you recently update to 6.12.x? When I did, I kept crashing every 2 to 3 days

Let me start out by saying. Its actually work correctly, just the display is totally jacked. I have nzbgetvpn running, on br0 so that it gets its own IP. All the containers that use that for networking work correctly too. they all have ports (not the ones show below, that is all kinds of wrong). And selecting the container, and opening the WebUI opens properly. No Issues, and the URL in the browser is correct too. The top one in the red box is correct, that is the correct IP and Port for it (and it works) every other one in the box are exactly the sae, and incorrect for both IP and Port. (but still open to the correct IP/Port when the WebUI is selected. Any thoughts on why that might be?

Ah, apparently the image-name is the repository. Thanks everyone!

Thanks for the assist. @Kilrah I was looking at that, but I haven't figured out how to specify an internal docker image. The Repository and Registry URL lines don't seem able to allow and internal "docker run" command. All the other path variables are easy enough. I am just not sure how to add the RUN part of the command. It might be as easy as clicking the Icon and selecting Start. but I still don't know how to tell it which image to start

In the end, I created my own docker image, using ubuntu, install ffmpeg and exiftool to do my processing. Now I just need direction on how I can get it to stay on the docker page when its not running. Currently I have to 'docker run' it every time. would be nice to have it in the docker page, that I can just press start. are there directions on that somewhere?

I would LOVE a Docker that contains FFMPG. I would be forever thankful! If there is anything I can do to help. Even if its ordering PIZZA!

Any change FFMPEG could get added to this tool? and FFPROBE?

On Occasion but rarely, mostly when I want to download an audiobook directly to the server. Perhaps there are other options. Although, since 6.12.2 and .3 I haven't used it at all (always off) so, I don't see how its affecting things

@JorgeB I do have it installed, but it rarely runs. Why?

Yes I upgraded to 6.12.3 but it did the same thing. Only worse. you can see from the image, the array things it not running, but it is, docker and all its internal IP's still work eyrie-diagnostics-20230726-1408.zip

I just received a new 14TB drives. I ran the Pre-Clean (full cycle - no issues) then added it to the array. The system rebuilt with the new drive in but it still say unfomated. I clicked the "Format" and "Yes I really want too" buttons. but it fails Any Ideas? hardhome-diagnostics-20230310-0804.zip

How exactly, It's mentioned above that you can download it from a 'Slackware Repository' but where is that? If I put it in any of the directories mentioned, it gets installed at startup... is that how NerdPack is doing it? I use several of the tools in NerdPack, and have noticed the absence of the author. Given that its free, he clearly has no obligation to continure, but it puts people in a bind without knowledge of how to do this ourselves. I personally use the list below, BUT my biggest need is EXIFTOOL, since I am a photographer. but it has not been updated in a LONG time and there are features I need in the newer 12.xx versions that I can not find anywhere. atop-2.2 borg exiftool-11.93... iftop-1.0.4 iotop-0.6 ncurses-terminfo-6.1.20191130 perl-5.32.0 python-setuptools-57.4.0 screen-4.8 sshfs-fuse-2.8 tmux-3.2 unrar-5.8.5

Done, thanks!

I had an old WD Red drive that I wanted to move the data off of. Its enclosure has been having issues lately with only periodically showing up on my Windows system. I removed the drive, added it to a tray and inserted it into my Unraid system. The Blue light came on for a few seconds, but nothing shows up in the Unassigned Devices tab. ls /dev/sd* doesnt not show another device other than what is in my system. How do I find out what error happened? This is the log After doing a Unassigned Disk Refesh, inserting disks, then Refreshing again Jul 26 10:47:20 Hardhome unassigned.devices: Refreshed Disks and Configuration. Jul 26 10:56:43 Hardhome kernel: mpt3sas_cm0: log_info(0x31110e05): originator(PL), code(0x11), sub_code(0x0e05) Jul 26 10:57:04 Hardhome kernel: scsi 9:0:16:0: attempting task abort!scmd(0x00000000d21a4040), outstanding for 22268 ms & timeout 20000 ms Jul 26 10:57:04 Hardhome kernel: scsi 9:0:16:0: tag#528 CDB: opcode=0x12 12 00 00 00 24 00 Jul 26 10:57:04 Hardhome kernel: scsi target9:0:16: handle(0x0019), sas_address(0x5003048000a56821), phy(33) Jul 26 10:57:04 Hardhome kernel: scsi target9:0:16: enclosure logical id(0x5003048000a5683f), slot(21) Jul 26 10:57:04 Hardhome kernel: scsi target9:0:16: enclosure level(0x0000), connector name( ) Jul 26 10:57:05 Hardhome kernel: scsi 9:0:16:0: task abort: SUCCESS scmd(0x00000000d21a4040) Jul 26 10:57:05 Hardhome kernel: end_device-9:0:16: add: handle(0x0019), sas_addr(0x5003048000a56821) Jul 26 10:57:05 Hardhome kernel: mpt3sas_cm0: mpt3sas_transport_port_remove: removed: sas_addr(0x5003048000a56821) Jul 26 10:57:05 Hardhome kernel: mpt3sas_cm0: removing handle(0x0019), sas_addr(0x5003048000a56821) Jul 26 10:57:05 Hardhome kernel: mpt3sas_cm0: enclosure logical id(0x5003048000a5683f), slot(21) Jul 26 10:57:05 Hardhome kernel: mpt3sas_cm0: enclosure level(0x0000), connector name( ) Jul 26 10:57:20 Hardhome webGUI: Successful login user root from 192.168.29.122 Jul 26 10:59:49 Hardhome kernel: mpt3sas_cm0: discovery errors(device blocked): sas_address(0x5003048000a56823), handle(0x001a) Jul 26 10:59:59 Hardhome unassigned.devices: Refreshed Disks and Configuration. hardhome-syslog-20220726-1604.zip hardhome-diagnostics-20220726-1105.zip

I have a friend who has a Photography Business that has asked for a simple nas. I am looking for a box that 1. has no compatibility issues with unraid hardware wise. 2. 6 to 8 hotswap bays 3. comes with a Motherboard and processor. 4. fairly compact and quite 5. NVMS would be nice but not required I was looking at QNAP but did know if they come with the motherboard Thanks!

Ran into a simular issue, it was working just fine GPU and all.. Then today, its only using the CPU.