My unraid license just automatically renewed. I logged into the server to check and it showed the old expire date, but when I clicked "manage unraid account" it did some negotiation with the unraid website and as part of that it updated the expiry date. This process took my array offline with no notification and took down roughly 12 VMs using unraid for storage. Furthermore, the array got stuck in a stopping state (Presumably since all 12 VMs were still trying to use the array) and I eventually had to reboot the box and then the proxmox nodes.

Is this expected behaviour (stopping the array with no user notice) and how do I stop it ever changing its license so this doesn't happen again?

I don't think that is expected; please post the diagnostics. Even if you rebooted once, as long as the save previous syslog to the flash drive is enabled, it should have the previous syslog.

6 hours ago, jfitzell said:

Is this expected behaviour (stopping the array with no user notice) and how do I stop it ever changing its license so this doesn't happen again?

I have not confirmed this with any staff but...

I believe limetech changed how the array runs, and yes when the license expires the array is stopped to prevent it from running indefinitely on an expired timer. Ive noticed this behavior on trials and when the USB is removed while only acting as a license and not a boot device.

Edited Tuesday at 01:23 PM1 day by MowMdown

You are correct, but it's different having an expired trial, which cannot be used, or having a paid license with updates expired, where you just cannot update, but can still use the current release.

Thanks all, it's definitely something related to the key expiring (but I was on a paid starter key that auto-renewed, not the trial). The bottom section (trying to delete /mnt/user) then repeats in the logs until I rebooted the box. To be honest, it's scared me off unraid and I spent last night moving all my VMs onto a new ZFS setup.

Jul 21 12:23:52 J1900 emhttpd: error: get_key_info, 741: Invalid argument (22): stat: /boot/config/Starter.key
Jul 21 12:23:53 J1900 emhttpd: Unregistered Trial - expired (EEXPIRED)
Jul 21 12:23:53 J1900 emhttpd: error: malloc_share_locations, 8649: Operation not supported (95): getxattr: /mnt/user/appdata
Jul 21 12:23:53 J1900 emhttpd: EEXPIRED: Stopping array
Jul 21 12:23:53 J1900 emhttpd: Starter key detected, GUID: ***** FILE: /boot/config/Starter.key
Jul 21 12:23:53 J1900 emhttpd: error: malloc_share_locations, 8649: Operation not supported (95): getxattr: /mnt/user/appdata
Jul 21 12:23:53 J1900 kernel: mdcmd (47): nocheck cancel
Jul 21 12:23:54 J1900 emhttpd: Spinning up all drives...
Jul 21 12:23:54 J1900 emhttpd: read SMART /dev/sdb
Jul 21 12:23:54 J1900 emhttpd: read SMART /dev/sdc
Jul 21 12:23:54 J1900 emhttpd: read SMART /dev/sda
Jul 21 12:23:54 J1900 emhttpd: Stopping services...
Jul 21 12:23:54 J1900 emhttpd: shcmd (126): /etc/rc.d/rc.samba stop
Jul 21 12:23:54 J1900 rc.samba: Stopping Samba server daemon...
Jul 21 12:23:54 J1900 rc.samba: kill 1856963
Jul 21 12:23:55 J1900 rc.samba: killall --ns 2053439 smbd nmbd wsdd2 winbindd
Jul 21 12:23:56 J1900 wsdd2[1856977]: 'Terminated' signal received.
Jul 21 12:23:56 J1900 wsdd2[1856977]: terminating.
Jul 21 12:23:56 J1900 winbindd[1856981]: [2026/07/21 12:23:56.004299,  0, traceid=1] ../../source3/winbindd/winbindd_dual.c:1984(winbindd_sig_term_handler)
Jul 21 12:23:56 J1900 winbindd[1856981]:   Got sig[15] terminate (is_parent=1)
Jul 21 12:23:56 J1900 rc.samba: Samba server daemon...  Stopped.
Jul 21 12:23:56 J1900 emhttpd: shcmd (127): rm -f /etc/avahi/services/smb.service
Jul 21 12:23:56 J1900 avahi-daemon[1856899]: Files changed, reloading.
Jul 21 12:23:56 J1900 avahi-daemon[1856899]: Service group file /services/smb.service vanished, removing services.
Jul 21 12:23:56 J1900 emhttpd: shcmd (129): /etc/rc.d/rc.nfsd stop
Jul 21 12:23:56 J1900 rc.nfsd: Stopping NFS server daemon...
Jul 21 12:23:56 J1900 rc.nfsd: /usr/sbin/rpc.nfsd 0
Jul 21 12:23:57 J1900 rpc.mountd[1856497]: Caught signal 15, un-registering and exiting.
Jul 21 12:23:57 J1900 rc.nfsd: /usr/sbin/exportfs -au
Jul 21 12:23:57 J1900 rc.nfsd: NFS server daemon...  Stopped.
Jul 21 12:23:57 J1900 emhttpd: Stopping mover...
Jul 21 12:23:57 J1900 emhttpd: shcmd (130): /usr/local/sbin/mover stop
Jul 21 12:23:57 J1900 root: mover: not running
Jul 21 12:23:57 J1900 emhttpd: Sync filesystems...
Jul 21 12:23:57 J1900 emhttpd: shcmd (131): sync
Jul 21 12:23:57 J1900 emhttpd: shcmd (132): /usr/sbin/zfs unmount -a
Jul 21 12:23:57 J1900 emhttpd: shcmd (133): umount /mnt/user
Jul 21 12:23:57 J1900 root: umount: /mnt/user: not mounted.
Jul 21 12:23:57 J1900 emhttpd: shcmd (133): exit status: 32
Jul 21 12:23:57 J1900 emhttpd: shcmd (134): rmdir /mnt/user
Jul 21 12:23:57 J1900 root: rmdir: failed to remove '/mnt/user': Directory not empty
Jul 21 12:23:57 J1900 emhttpd: shcmd (134): exit status: 1
Jul 21 12:23:57 J1900 emhttpd: shcmd (136): rm -f /boot/config/plugins/dynamix/mover.cron
Jul 21 12:23:57 J1900 emhttpd: shcmd (137): /usr/local/sbin/update_cron
Jul 21 12:23:57 J1900 emhttpd: Retry unmounting user share(s)...
Jul 21 12:24:02 J1900 emhttpd: shcmd (138): umount /mnt/user
Jul 21 12:24:02 J1900 root: umount: /mnt/user: not mounted.

7 hours ago, jfitzell said:

Jul 21 12:23:52 J1900 emhttpd: error: get_key_info, 741: Invalid argument (22): stat: /boot/config/Starter.key

This means the key was not valid. Possibly it caught the new key in the process of being written.

7 hours ago, jfitzell said:

Jul 21 12:23:53 J1900 emhttpd: Unregistered Trial - expired (EEXPIRED)

Since the paid key was invalid, it looked for another one and found an expired trial, but this by itself is not a problem, since it would not matter if a valid key was installed.

7 hours ago, jfitzell said:

Jul 21 12:23:53 J1900 emhttpd: Starter key detected, GUID: ****** FILE: /boot/config/Starter.key

It then detected the correct new key, but the array had already started to stop.

7 hours ago, jfitzell said:

Jul 21 12:23:53 J1900 emhttpd: error: malloc_share_locations, 8649: Operation not supported (95): getxattr: /mnt/user/appdata

The array failing to stop is unrelated to the key issues and likely related to this, which suggests something is writing something to appdata outside Unraid.

This is the first time I ever seen this happening, so possibly an isolated/timing issue, but I'll test myself and will forward this issue to LT even if I can't repro in case this can be improved.