SMB behaviour after applying 25.10

TrueNAS General
,
1

I have recently updated my production storage to 25.10.

I have noticed couple of times that while trying to access my SMB share Truenas will report empty drive, when I refresh couple of times my content will show up correctly.

It also happens in opposite direction too - at one point, I tried to open PDF file which was clearly there and my windows client reported that the file I am looking for is no longer there (it opened correctly few seconds later). I have done all “have you tried turning it off and on again”, but the issue repeated itself. No errors are recorded.

My setup includes multichanell SMB and it is also true that my windows machine recently updated to 25H2 so there are many “moving parts” which makes it hard to pinpoint where exactly issue happens.

So this is just a record that something is happening (data is/appears safe), so if anyone has a clue or idea where to look for issues, or you notice something similar, please let me know.

2

Propably the same issue as here

2 Likes
3

Thanks, I did browse the forum but moved past suggested thread (because it included NFS in subject, which I do not use).

This appears to describe my problem (and I am not alone :).

4

I can confirm I have the same issue on multiple machines with Windows 11/10. Was really stressed about it for the first couple of times, thinking everything was gone. :grimacing:

5

I’m not seeing this in my lab with default settings for 25.10.0. I’ll need explanation of minimal test case for this, or someone to PM me for a teamviewer session some time next week (I’ll probably have to install development tools and debug symbols so that I can gdb attach to the SMB session).

Examples of relevant information:

  1. share configuration midclt call sharing.smb.query | jq and select out relevant share config
  2. ACL configuration getfacl <path> or nfs4xdr_getfacl <path> depending on underlying ACL type.
  3. whether share path is being accessed by apps / containers / NFS server as well as the SMB server.

Reposting here, you can send message directly to me.

2 Likes
6

Just to add to public conversation; if this issue happens in both NFS and SMB shares, this is unlikely SMB problem, it happens somewhere else.

7

That thread is the only time I have seen NFS mentioned, yet I have seen over 15 people complain about SMB. Happy to be wrong, also this is not solved, hell it is not even acknowledged yet.

1 Like
8

Maybe you could explain how you are testing? Did you just create a share and put a file in it? If so then yup, you ain’t probably ever going to see it.

9

I marked it solved because it is (almost certainly) explained in above mentioned thread where more people included their experiences.

I have not focused on NFS part (I am not using it), but it occured to me that if the issue happens with NFS as well, that would mean that the source of the problem is not NFS/SMB but something else, likely in “lower” levels of truenas (for example, we know that ZFS version changed and maybe there are some other arhitectural changes which might lead to this issue).

10

Yes true, we have been explaining it for awhile now. Perhaps we need a “Explained” topic.

11

I’ll add my voice to those who’ve experience SMB flakiness after updating to 25.10. The first symptom I noticed was using the “Go up” button in Windows Explorer to navigate to the parent folder inside an SMB share would fail with the message that the location does not exist. If I retry a few times it would eventually work. Further, opening a share location would sometimes show zero or only 1 subfolder instead of the full contents. Refreshing once usually restored full visibility. Finally, editing a Word document on a share had trouble saving, I deduce because Word no longer found the file’s location.

12

Is this true?

Confirmed Multiprotocol Conflict: Disabling NFS Shares to Restore Time Machine Leases

The grep output from /etc/smb4.conf pinpoints the exact problem: Your TrueNAS SCALE 25.10.0.1 system is in multiprotocol mode (SMB + NFS shares on the same pool/datasets), which globally disables SMB3 leases and AAPL/fruit extensions needed for Time Machine sparsebundle access. This forces RDONLY leases on files like Info.plist, blocking writes/renames (your “access denied” and incomplete bundle creation).

Workaround is to host Time Machine on a pool without NFS?

The docs indicate..

Adding a Basic Time Machine SMB Share | TrueNAS Documentation Hub

This means that in TrueNAS 25.04 and later, multiprotocol shares are incompatible with Time Machine shares on the same system. To prevent service interruption, Time Machine users should make sure that no multiprotocol shares are configured on TrueNAS…

There are no multi-protocol shares configured… but I have both NFS and SMB within the same pool. Struggling to get time machine working again here..