smb locking and Macs

[Giuliano Gavazzi]

I have a FreeNAS-11.1-U6 installation on a iXSystems 1U certified server. It has several datasets shared. All the shares and read/write in smb, with some being also shared in afp, but with Read-only Access for all users in this last protocol. My users noticed that some times Excel files were being accessed by two users in read/write mode at the same time. So I did some test and noticed that if a user (user1) was connected from a remote site (via a Sonicwall firewall/router) and so his connection was not as stable as internal ones, his samba process pid would change once in a while (quite often though) and with the process id change also the lock held on the file was lost (the corresponding RDWR entry in smbstatus would disappear). Only a save command from Excel would regrab the lock. Problem is, if another user (user2) attempted to open the same file when the first one had temporarily lost the lock on it, the second user would effectively open the file in read/write mode (and acquire the lock) on a file that was opened by the first user. So if for instance user2 had made a change and saved it and closed the file, a subsequent save by user1 would overwrite user2 changes. This behaviour has so far been noticed only from Macs running 10.11.6 (El Capitan) and conne

 

[anodos]

I have a FreeNAS-11.1-U6 installation on a iXSystems 1U certified server. It has several datasets shared. All the shares and read/write in smb, with some being also shared in afp, but with Read-only Access for all users in this last protocol. My users noticed that some times Excel files were being accessed by two users in read/write mode at the same time. So I did some test and noticed that if a user (user1) was connected from a remote site (via a Sonicwall firewall/router) and so his connection was not as stable as internal ones, his samba process pid would change once in a while (quite often though) and with the process id change also the lock held on the file was lost (the corresponding RDWR entry in smbstatus would disappear). Only a save command from Excel would regrab the lock. Problem is, if another user (user2) attempted to open the same file when the first one had temporarily lost the lock on it, the second user would effectively open the file in read/write mode (and acquire the lock) on a file that was opened by the first user. So if for instance user2 had made a change and saved it and closed the file, a subsequent save by user1 would overwrite user2 changes. This behaviour has so far been noticed only from Macs running 10.11.6 (El Capitan) and conne

If you can easily reproduce this, can you get a pcap of the behavior?

 

[anodos]

Also attach output of "testparm -s"

 

[Giuliano Gavazzi]

Also attach output of "testparm -s"

Thank you:
First an update: the problem arises when TCP timeout is set to a relatively short value at the firewall for this particular type of connection (defined by the port). That means that the lock is relinquished when a connection is closed, which might be the expected behaviour.
The tests were performed on the scanner share, and in the configuration below I had already modified the lock parameter from the default ones to no avail:

Server role: ROLE_STANDALONE

# Global parameters
[global]
dos charset = CP437
lm announce = Yes
nsupdate command = /usr/local/bin/samba-nsupdate -g
logging = file
max log size = 51200
kernel change notify = No
panic action = /usr/local/libexec/samba/samba-backtrace
disable spoolss = Yes
load printers = No
printcap name = /dev/null
server min protocol = SMB2_02
time server = Yes
unix extensions = No
client ipc signing = No
client signing = No
map to guest = Bad User
ntlm auth = ntlmv1-permitted
obey pam restrictions = Yes
security = USER
server role = standalone server
server signing = No
deadtime = 15
max open files = 939341
dns proxy = No
catia:mappings = 0x22:0xa8,0x2a:0xa4,0x2f:0xf8,0x3a:0xf7,0x3c:0xab,0x3e:0xbb,0x3f:0xbf,0x5c:0xff,0x7c:0xa6
idmap config *: range = 90000001-100000000
idmap config * : backend = tdb
mangled names = no
store dos attributes = Yes
kernel oplocks = Yes
level2 oplocks = No
directory name cache size = 0
dos filemode = Yes
acl allow execute always = Yes
ea support = Yes
create mask = 0666
directory mask = 0777


[scanner]
path = "/mnt/raid/scanner"
veto files = /.snapshot/.windows/.mac/.zfs/
oplocks = No
strict locking = Yes
read only = No
vfs objects = zfs_space zfsacl streams_xattr
zfsacl:acesort = dontcare
nfs4:chown = true
nfs4:acedup = merge
nfs4:mode = special

I will post later other details.

 

[anodos]

You probably will get much better behavior if you can keep sessions established. Otherwise I have a feeling there will be ongoing problems.

 

[Giuliano Gavazzi]

You probably will get much better behavior if you can keep sessions established. Otherwise I have a feeling there will be ongoing problems.

Do you mean by increasing the TCP timeout for those particular connections? I did indeed yesterday increase the timeout to 20 minutes and that change made the sessions stick. Only after there the client computer is disconnected from the network for a long time (but <20min of course) the session is lost. Unfortunately Mac OS reopens the connection transparently thus making it possible for the user to save changes to a file that was opened in the previous session, and this can overwrite someone else changes.

 

[anodos]

Do you mean by increasing the TCP timeout for those particular connections? I did indeed yesterday increase the timeout to 20 minutes and that change made the sessions stick. Only after there the client computer is disconnected from the network for a long time (but <20min of course) the session is lost. Unfortunately Mac OS reopens the connection transparently thus making it possible for the user to save changes to a file that was opened in the previous session, and this can overwrite someone else changes.

Perhaps try setting the following auxiliary parameter under Services->SMB deadtime = 0. If this makes the problem go away, you can extend it to maybe a couple of hours (or a business day).

 

[Giuliano Gavazzi]

Perhaps try setting the following auxiliary parameter under Services->SMB deadtime = 0. If this makes the problem go away, you can extend it to maybe a couple of hours (or a business day).

Thanks anodos, I saw that parameter before, but thought that as it "takes effect if the number of open files is zero" then it should be irrelevant to preserve locks. I am trying it anyway and am testing it overnight.

 

[Giuliano Gavazzi]

I don't see an improvement with the deadtime parameter set to 0, but it does not surprise me. Unfortunately even working on the computer, if no activity is forced on the smb connection (keeping a file open in not enough) the inactivity of the TCP connection will eventually cause the firewall to drop the natted connection. Increasing the timeout of the specific TCP connections on the firewall will help as far as the client IP does not change. Probably smb has not be designed with this in mind, or else a lock would stick across connections (the client would have to store a token that proves that he owns the lock).

 

[anodos]

Were these parameters added to try to debug the problem?

Code:

kernel oplocks = Yes
level2 oplocks = No

 

[Giuliano Gavazzi]

Were these parameters added to try to debug the problem?

Code:

kernel oplocks = Yes
level2 oplocks = No

Yes, particularly as most systems connected to these shares are Mac OS ( 10.11.6 and later).

 

[Giuliano Gavazzi]

and
oplocks = No
too, as, if I understand well, these are supported only by Windows systems.