TrevP

use
//192.168.0.30/unraid /mnt/unraid cifs rw,guest,_netdev,noatime,noserverino 0 0 not
//192.168.0.30/mnt/user/unraid /mnt/unraid cifs rw,guest,_netdev,noatime,noserverino,cache=none 0 0Note the two changes. You want to mount the "Share", not the path; and I no longer disable caching by default. The standard "cache=strict" is used by default and good enough for the vast majority of uses.

I use SMB exclusively between all my Linux servers and Unraid, all using systemd automount. On Unraid, export the share using SMB. On the Linux client, here is my setup:
/etc/fstab
//<unraid host>/<sharename> /mnt/<mountpoint> cifs rw,guest,uid=99,gid=100,_netdev,noatime,noserverino,noperm,cache=none,x-systemd.automount,x-systemd.idle-timeout=600,exec 0 0 What this does:
rw = read and write access
guest = connect without a username/password (guest access)
uid=99 = treat files as owned by local user ID 99
gid=100 = treat files as owned by local group ID 100
_netdev = wait for network before mounting
noatime = don’t update “last accessed” timestamps
noserverino = don’t use server inode numbers (avoid inode-related issues)
noperm = don’t enforce local Linux permissions; let the server decide
cache=none = disable client-side caching (reduce stale reads)
x-systemd.automount = mount on first access, not at boot
x-systemd.idle-timeout=600 = unmount after 10 minutes of inactivity
exec = allow running programs from the mount
final 0 = don’t include in dump backups
final 0 = don’t run fsck checks on it

Change the above for your requirements.
I also create a dedicated “Unraid” identity on the Linux box so UID/GID 99/100 are clearly identifiable when you do ls -l:

# make sure group 100 exists (name it whatever you want) groupadd -g 100 unraid # create a system user with no home and no shell, pinned to UID 99 / GID 100 useradd -u 99 -g 100 -M -r -s /usr/sbin/nologin unraidThen run the following:
mkdir -p /mnt/<mountpoint> systemctl daemon-reload Sanity checks (make sure the required systemd targets/units are active):
systemctl is-enabled remote-fs.target systemctl is-active remote-fs.target (Optional) If you want to confirm systemd actually created the automount unit:
systemctl list-units --type=automount | grep -F "<mountpoint>" Important note about automount: x-systemd.automount is mount-on-access. It will NOT mount the share until something actually touches the mountpoint. So if you do this and then run df, you’re not going to see anything yet, that’s expected. df will only show it after the mount is triggered.
Now trigger the mount by accessing the directory:
cd /mnt/<mountpoint> # or: ls /mnt/<mountpoint> After that, df should show the mounted share.

In digging further (and without rebooting, on purpose), I’m pretty confident the root cause is inconsistent state between server-state.php and the GraphQL registration object. It looks like the GraphQL registration state is never updated after the original trial is created.
1. server-state.php (Connect state)
From:
/plugins/dynamix.my.servers/data/server-state.php I see:
"regTy": "Unleashed", "state": "UNLEASHED", "expireTime": 0, "regTm": 1764185767000, "regExp": 1795721767000 So Connect / server-state.php correctly thinks:
I’m on an Unleashed license
There’s no trial expiry (expireTime = 0)
2. GraphQL registration state (before any restart)
Using this query:
query { registration { id type state expiration updateExpiration } } I get:
{ "data": { "registration": { "id": "…", "type": "TRIAL", "state": "TRIAL", "expiration": "1764017265000", "updateExpiration": null } } } The important part is the expiration value:
1764017265000 is the timestamp for when my original trial expired
It does not match my extended trial expiry
It also does not reflect the later Unleashed purchase
So it looks like:
The GraphQL registration object was set up when the original trial started
It never updated when the trial was extended
It still hadn’t updated even after installing the Unleashed key
Meanwhile, server-state.php had already updated and was reporting regTy: "Unleashed", state: "UNLEASHED", expireTime: 0.
That would explain why parts of the UI can show “Unleashed” (anything reading server-state.php) and “Trial/Unlicensed” at the same time (anything reading the GraphQL registration state).
3. Forcing a refresh of the API state
To test this theory, I restarted just the Unraid API service (still no reboot):
unraid-api restart Then I re-ran the same GraphQL query:
query { registration { id type state expiration updateExpiration } } After the restart, GraphQL now returns:
{ "data": { "registration": { "id": "…", "type": "UNLEASHED", "state": "UNLEASHED", "expiration": "0", "updateExpiration": "1795721767000" } } } This now matches server-state.php:
type / state → UNLEASHED
expiration → 0 (no trial)
updateExpiration → same future timestamp as regExp in server-state.php
And as you can see in the screenshot below, once the API was restarted, the UI also updated and now shows everything correctly as Unleashed.
4. What this suggests
Putting it all together:
The registration data exposed by GraphQL is:
Created when the original trial is created
Not updated when the trial is extended
Not updated when an Unleashed key is installed
server-state.php does get updated to UNLEASHED immediately after installing the key
Restarting unraid-api (or rebooting the server) forces GraphQL to refresh and then it correctly reports UNLEASHED with no trial

So the root issue seems to be:

The GraphQL registration state is stale and only refreshed when the Unraid API service starts. It doesn’t get updated when a trial is extended or when a paid license is installed, even though server-state.php already has the correct Unleashed state.

If the UI is mixing server-state.php and GraphQL as data sources, that would naturally produce exactly the mixed “Unleashed” + “Trial/Unlicensed” messages I was seeing until unraid-api was restarted. After restarting the API, both GraphQL and the UI now fully agree on the Unleashed license.

Which brings up.. if simple registration information isn't updated in GraphQL, what other things are also not updated?

After experimentation, I was also seeing the same thing using SMB exports. After CA Mover tuning runs, AND if you have remove top level folders enabled (to keep the “Some or all files unprotected” warning at bay), I found the actual solution in this thread : PSA/HOW-TO Proper fix for SMB stale file handle
Hint: add "noserverino" to the fstab mount line
(Details of "why" this works is in the link)

The magic fstab line that works for me is this:
//<UNRAIDSERVER>/<SHARENAME> <LOCALMOUNTPOINT> cifs rw,guest,uid=99,gid=100,_netdev,noatime,noserverino,noperm,exec 0 0

This solves everything for me. I suspect this will also work for NFS mounts as well.
Hope it helps others.

Edit: this does NOT work with NFS mounts as "noserverino" is a cifs only option. NFS mounts will go stale if the "cache" mount point disappears.