Intermittant access denied with SMB mounts

[dlondon]

Hi,

For some time I have been seeing the access denied red circle with white dash in the middle for a small but frustrated group of users on our campus.

The access will be denied and then come back again with no intervention. I have even seen it on my machine and it was just flashing denied ... allowed ... and then after about 20 seconds came good again

I have tried updating the machines to the latest OS but that makes no difference.

In the system.log I see this line which may be helpful:

Apr 24 11:27:45 SIS-0055-osx-l smbremountserver[810]: no path for address 0x10e663000

but so far I can't figure it out.

I have people on good parts of the network 1Gbps and others on older 100Mbps with the issue. Some have old machines and some are new.

Common sources of the problem may still be some of the core network infrastucture, DNS and the file servers

Has anyone seen this sort of intermittent access denied issue and if so what was the cause in your case?

Regards,

David

[mpebley]

We have also seen this on some of our Netfilers.
Try mounting the shares with cifs:// (not smb://) and mount down to the target folder desired to be accessed, not the root directory of the share. If they mount further down the share's directory path, we have had better results (something to do with user not having full rights to the root dir).

[dlondon]

Thanks Michael,

Had already tried cifs instead of smb. No change.

When you say mount down to the target folder do you mean share that folder or just have the connection as smb://servername/folder1/folder2/targetfolder ?

Regards,

David

[dwenger]

We ran across something similar, combined with abysmal performance on the mounted shares. It was due to varying permissions in the share, and our filer only supporting SMBv1 mounts. SMB signing has been an issue for many as well. Specifying cifs:// on its own to try to map using SMBv1 proved inconsistent. After creating a custom SMB configuration, the issue has not resurfaced.

If not all your Macs are up to 10.12.x, be mindful of the proper syntax, as it has changed. This post briefly discusses the recent changes.

This is essentially what we're using to set the SMB configuration for our environment:

#!/bin/bash

smbConfiguration="/private/etc/nsmb.conf"


touch "$smbConfiguration"
cat > "$smbConfiguration" <<EOF
[default]
signing_required=no
protocol_vers_map=1
EOF

killall Finder

[dlondon]

Thanks Daniel,

Apparently we have a higher level on the vfilers here as they have had smb3 and smb4 connections working.

Great script - more elegant than mine ... thanks for sharing

Regards,

David

[cindySingh]

Hi @dwenger I tried this with 2 of my users, unfortunately it did not help.
Checked with server team, they verified access is ok. Not sure what is causing the issue.

Thanks
CinSin

[dlondon]

Hi @dwenger ,

Still trying to get to the bottom of this. Do you know how to set the value kloglevel in the nsmb.conf file? That is what are the valid levels?

Regards,

David

[dwenger]

Hi @dlondon,

I'm not exactly sure on kloglevel. I found this article, but I'm not sure if things may have changed with it since 10.9.

[dlondon]

Hi @dwenger ,

yes that seems to say if you want all logging it would be 0x15

The thing is I can't see any change. Maybe I need to reboot - will check. The only place I see smb info is in console and the device

certainly not in system log

Regards,

David London

[sdoyle]

Hi All,
I just wondered whether there's been any updates on this - I'm experiencing exactly the same issue described by dlondon with a small set of High Sierra users seeing intermittent no access red icons on a volume shared from a Dell EMC Compellent NAS. Sometimes the folders look like a Christmas tree with red flickering on and off. I've extensively tested this but no windows users or other versions of MacOS have this issue.
I've also tested SMB1 and while this is stable it's running about 20% of the speed of SMB3. This isn't useful in my environment because we're shifting around files with typical sizes up to 60 GB and sometimes larger.
I'm also seeing intermittent failures when copying too and from the NAS volumes (-36 and -8084 errors typically). This is not happening when copying files around on our other NASs or SAN.
Any feedback appreciated,
Thanks
Sean Doyle

[dlondon]

Hi,

This is still an issue for us but we are returning our Data Centre back on site from the outsourced one we have been using and I believe will not be using vfilers so am hoping for a different set of issues :)

Our only workaround so far has been to use WebDav. Unfortunately there are a few characters that webdav can't understand - they look like "." and that stops access. These characters are created by the smb users when naming files. I also don't like WebDav as people see it looking like a file system and stay connected all day long and even open files accross the webdav connection. This has caused file corruption in the past. I hammer on to the users to copy the file local and then open and work on it but worry they will slack off

Regards,

David

[sdoyle]

Apologies for not returning to this thread sooner - I discovered that upgrading to macOS Mojave completely resolved this issue and improved network thruput considerably. I spent a fair amount of time with Wireshark examining the SMB traffic and realised that with High Sierra there's a disparity in the way SMB credits are exchanged between the NAS and macOS clients - eventually the clients end up with no credits and the connection is lost. The connection is then re-established.

[dlondon]

Hi @sdoyle that's great! I switched a lot of people to WebDAV but that has its own problems. I'll work on getting them to use SMB again. In fact I've just refreshed the MacBook of one user that had the worst time with this so will get her back on SMB and see how it goes.