Can't see new files / directories in SMB share

Joined
Jul 13, 2013
Messages
286
For a change, this is an IXSystems FreeNAS Mini in use at a client site. It has one small pool (three-way mirror of 6TB), and one dataset is being shared out via SMB. Not AD or any other directory service, we authenticate using usernames configured on the FreeNAS box.

We have fewer than 10 user hitting the server; mostly reading or writing somewhat big files (some up towards 50MB, most smaller), at intervals (storing scans of historic photos or documents, loading them back to study them, etc.) The systems are a wide mix, with mostly Macintosh laptops (and not brand-new models), with at least one Linux box and my Windows-10 laptop.

We're all logged in as the same FreeNAS user, which is the owner for the dataset and files in it.

The dashboard says we're up-to-date with the 11.2-Stable train. Disk is nowhere near full (less than 1TB used).

Everybody (so every kind of computer) has seen some variation of this problem. It finally got to me, for the first time in a week, this morning. The cient came over to show me a directory structure out on the server -- and my computer couldn't see it. On her laptop "U:\work\Old and Original Stereo Scans Karen Only" (wait, she's a Mac; so it was that directory, but she expressed the path differently) had two subdirectories in it; on mine it was empty. It remained empty when I refreshed the file explorer window, and it remained empty when I started back at the desktop and navigated to that directory from scratch. I opened an SSH session to the server and examined that directory; it showed the subdirectories present and with expected owner and permissions.

Code:
[bup@ucnas ~]$ ls -l /mnt/zpuc/uc/work/Old\ and\ Original\ Stereo\ Scans\ Karen\ Only/
total 17
drwxrwxr-x+  2 uc  uc  309 Jan 13 10:57 old SVs backs
drwxrwxr-x+ 14 uc  uc   15 Jan 13 11:36 old SVs fronts to spin
[bup@ucnas ~]$ getfacl /mnt/zpuc/uc/work/Old\ and\ Original\ Stereo\ Scans\ Karen\ Only/
# file: /mnt/zpuc/uc/work/Old and Original Stereo Scans Karen Only/
# owner: uc
# group: uc
            owner@:rwxpDdaARWcCos:fd----I:allow
            group@:rwxpDdaARWcCos:fd----I:allow
         everyone@:r-x---a-R-c---:fd----I:allow
[bup@ucnas ~]$ getfacl /mnt/zpuc/uc/work/Old\ and\ Original\ Stereo\ Scans\ Karen\ Only/*
# file: /mnt/zpuc/uc/work/Old and Original Stereo Scans Karen Only/old SVs backs
# owner: uc
# group: uc
            owner@:rwxpDdaARWcCos:fd----I:allow
            group@:rwxpDdaARWcCos:fd----I:allow
         everyone@:r-x---a-R-c---:fd----I:allow

# file: /mnt/zpuc/uc/work/Old and Original Stereo Scans Karen Only/old SVs fronts to spin
# owner: uc
# group: uc
            owner@:rwxpDdaARWcCos:fd----I:allow
            group@:rwxpDdaARWcCos:fd----I:allow
         everyone@:r-x---a-R-c---:fd----I:allow


It stayed the same for more than half an hour (with refreshes periodically) since I was waiting for a couple of big operations using the share to complete. At this point I unmapped the network drive U:, and re-mapped it to point to the same share and logged in with the same username and password. I could then immediately see the subdirectories (and files in them and further subdirectories, etc.), matching what her laptop showed, what LS on the actual server showed.

As I say, everybody has had something vaguely like this -- a temporary access issue to some file or directory. Some were reported as inability to create a file rather than inability to see a file or directory the way I had.

Note we're sharing via SMB. From what I read that's the only thing worth trying for a mixed group of systems like this? I read that sharing the same dataset by both SMB and AFP is not recommended; and of course the Windows and Linux boxes don't want to hear about AFP so only AFP isn't an option.

Client is a bit tetchy; we're at the "this doesn't seem stable and reliable" point (which seems entirely fair; we've spent time talking about some access issue every day for the last week, and never really found a "resolution").

Guest logins are disabled, so I'm sure nobody is accidentally coming in as guest. All the files/directories I've documented problems with so far have the protections I expect and the owner I expect.

And I don't have problems like this on my home server, running the same train; it has fewer users and just Windows most days, but it's where all my files live and I use it constantly and would notice if it suddenly couldn't see things.

Ideas?
 
Joined
Jul 13, 2013
Messages
286
Or, as one user put it just now, "I save a scan and it's not visible on the NAS for 7 minutes". No reboot, reconnect, or any other obvious reason for things to change then. (I don't think it's consistently 7 minutes, I think this is the most recent instance carefully measured to document how bit it is.) This example was on a Mac (the shares are via SMB as explained above; share Mac and Windows user base).

Really needing some ideas here!
 
Joined
Jul 13, 2013
Messages
286
No cause that I can shake a stick at, no. Hasn't repeated for me, but has for other people.
 
Joined
Jul 3, 2015
Messages
926
My initial thought is that if you have a lot of files/folders in that directory it may be taking a while to display. Try adding the below to your SMB Global Auxiliary Parameters and see if that helps.

allocation roundup size = 4096
ea support = no
store dos attributes = no
map archive = no
map hidden = no
map readonly = no
map system = no
 
Joined
Jul 13, 2013
Messages
286
From what I can tell with simple testing, this is helping quite a bit. We don't have really huge directories, but several hundred image files is common. I haven't gone to the point of shutting down both client and server between tests to be *sure* I've cleared cache on both ends, but it gets much faster access to file lists now than in my couple of tests before adding the parameters (around 7 seconds for a 500-file directory before, fractional seconds for a couple of different directories about that size afterwards; trying to use different one so I'm not just seeing cache performance).

So, that should help, just in general! I don't think it's likely to explain the 7 minute delay in seeing things one user reported, but I suppose I could be wrong.

A factor may have been that the WIFI was kind of overloaded; though, late Thursday when I was one of the last two there, things remained weirdly slow, so who knows? By moving to the dining room table from the living room I switched to a different satellite WIFI node (Netgear ORBI system), so that probably changed my basic performance parameters!

The big two-week death-march is done, so there won't be more than a couple of uses for the foreseeable future.
 
Top