Timeout mounting (SMBv3) File Sharing

[Dreyfuss]

Hi there!

We have a problem accessing file sharing via Mobile Access. After 120 minutes, the session is automatically disconnected (mounting to the file server, viewed with the command df -h). Only the user's session is 8 hours (with the same idle time). How do I set the mounting smb timeout to be equal to the user's session time?
Thanks in advance!
GAIA 80.30 - 23K Series

[PhoneBoy]

What precisely happens when the SMB file mount "times out."
Also, am pretty sure you're using the Linux 3.10 variant of R80.30 since it's not supported in Linux 2.16.

[Dreyfuss]

Hi.
Yes, we use 3.10 with 80.30.

When I do a "ls" from the /opt/CPcvpn-R80.30/mnt/cvpn_mnt directory the result is as follows. All directories that have a "?" are unmounted, despite users being logged (or not) in to the application.

ls: cannot access ml5092: Input/output error
ls: cannot access ml5096: Input/output error
ls: cannot access ml5100: Input/output error
ls: cannot access ml1591: Input/output error (notice this)
ls: cannot access ml5011: Input/output error (and this)
ls: cannot access ml5015: Input/output error
ls: cannot access ml5023: Input/output error
ls: cannot access ml5025: Input/output error
ls: cannot access ml5026: Input/output error
ls: cannot access ml5028: Input/output error
ls: cannot access ml5031: Input/output error
ls: cannot access ml5032: Input/output error
ls: cannot access ml5033: Input/output error
ls: cannot access ml5034: Input/output error
ls: cannot access ml5039: Input/output error
ls: cannot access ml5041: Input/output error
ls: cannot access ml5043: Input/output error
ls: cannot access ml5055: Input/output error
ls: cannot access ml5059: Input/output error
ls: cannot access ml5062: Input/output error
ls: cannot access ml5063: Input/output error
ls: cannot access ml5072: Input/output error
ls: cannot access ml5099: Input/output error
d????????? ? ? ? ? ? ml5062
d????????? ? ? ? ? ? ml5063
d????????? ? ? ? ? ? ml5072
d????????? ? ? ? ? ? ml5073
d????????? ? ? ? ? ? ml5075
d????????? ? ? ? ? ? ml5076
d????????? ? ? ? ? ? ml5077
d????????? ? ? ? ? ? ml5078
drwxr-xr-x 2 admin root 16384 Fev 17 2020 ml5079
d????????? ? ? ? ? ? ml5083
d????????? ? ? ? ? ? ml5084
drwxr-xr-x 2 admin root 16384 Out 7 2019 ml5085
d????????? ? ? ? ? ? ml5086
d????????? ? ? ? ? ? ml5087
d????????? ? ? ? ? ? ml5088
d????????? ? ? ? ? ? ml5090
d????????? ? ? ? ? ? ml5091
d????????? ? ? ? ? ? ml5092
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5093
d????????? ? ? ? ? ? ml5095
d????????? ? ? ? ? ? ml5096
d????????? ? ? ? ? ? ml5099
d????????? ? ? ? ? ? ml5100
drwxr-xr-x 2 admin root 16384 Mar 17 11:43 ml5101
drwxr-xr-x 2 admin root 0 Jun 20 2019 ml5102
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5103
drwxr-xr-x 2 admin root 65536 Abr 8 12:59 ml5104
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5105
drwxr-xr-x 2 admin root 16384 Out 7 2019 ml5106
drwxr-xr-x 2 admin root 16384 Set 23 2020 ml5107
drwxr-xr-x 2 admin root 16384 Out 18 2019 ml5108
drwxr-xr-x 2 admin root 16384 Jul 21 2020 ml5109

And in / proc / mount it looks like this:
//XXX.XXX.XXX.XXX/sp /opt/CPcvpn-R80.30/mnt/cvpn_mnt/ml1591 cifs rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=john.doe,domain=XXXXXX,uid=0,noforceuid,gid=0,noforcegid,addr=XXX.XXX.XXX.XXX,file_mode=0755,dir_mode=0755,nounix,mapposix,noperm,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1 0 0
//XXX.XXX.XXX.XXX/sof /opt/CPcvpn-R80.30/mnt/cvpn_mnt/ml5011 cifs rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=john.doe,domain=XXXXXX,uid=0,noforceuid,gid=0,noforcegid,addr=XXX.XXX.XXX.XXX,file_mode=0755,dir_mode=0755,nounix,mapposix,noperm,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1 0 0

Notice that the mapped folder ml1591 appear with errors in the ls command, but it appear mounted in proc / mount and / etc / mtab:

//XXX.XXX.XXX.XXX/sp /opt/CPcvpn-R80.30/mnt/cvpn_mnt/ml1591 cifs rw 0 0

[PhoneBoy]

This sounds like the connection being timed out of the connections table.
You might be able to increase the TCP timeout accordingly as a workaround.
However, I'd engage with the TAC here.

[Timothy_Hall]

What do you have set on this screen on the Mobile Access tab of the SmartDashboard:

There are also some other timers you should check on the "VPN Clients" screen above.  They are supposed to be sync'ed with the various Remote Access settings in the Global Properties of SmartConsole, but worth checking anyway.

[Dreyfuss]

Thanks for the reply, but all of my timeouts are the same. Both in legacy Mobile Access and global settings. There´s a TAC opened: 6-0002579376.

I´ve just changed the last one from 30 to 60 to 120: Disconnect idle sessions (Last picture) - didn´t work.

an important update: I left the command "watch ls" in the mounting that was created when I entered the application and until now no user has taken a timeout on their connection and the appearance of the assembly directory is the following only 2 inaccessible directories.
ll
ls: cannot access ml1591: Input / output error
ls: cannot access ml5059: Input / output error
total 1504
d ????????? ? ? ? ? ? ml1591
d ????????? ? ? ? ? ? ml5059
drwxr-xr-x 2 admin root 16384 Oct 7 2019 ml5085
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5093
drwxr-xr-x 2 admin root 16384 Oct 1 2020 ml5111
drwxr-xr-x 2 admin root 0 Jul 17 2020 ml5119
drwxr-xr-x 2 admin root 16384 Jun 21 2019 ml5154
drwxr-xr-x 2 admin root 16384 Jul 21 2020 ml5155
drwxr-xr-x 2 admin root 16384 Mar 16 2020 ml5161
drwxr-xr-x 2 admin root 16384 Oct 18 2019 ml5165
drwxr-xr-x 2 admin root 16384 Mar 17 11:43 ml5176
drwxr-xr-x 2 admin root 16384 Oct 1 2020 ml5177
drwxr-xr-x 2 admin root 16384 Dec 30 10:08 ml5178
drwxr-xr-x 2 admin root 16384 Dec 30 10:08 ml5179
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5181
drwxr-xr-x 2 admin root 16384 Oct 1 2020 ml5198
drwxr-xr-x 2 admin root 16384 Feb 10 2020 ml5199
drwxr-xr-x 2 admin root 16384 Sep 23 2020 ml5207
drwxr-xr-x 2 admin root 16384 Feb 17 2020 ml5212
drwxr-xr-x 2 admin root 16384 Mar 16 2020 ml5214
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5216
drwxr-xr-x 2 admin root 65536 Apr 8 12:59 ml5229
drwxr-xr-x 2 admin root 16384 Oct 18 2019 ml5233
drwxr-xr-x 2 admin root 16384 Oct 7 2019 ml5234
drwxr-xr-x 2 admin root 16384 Oct 7 2019 ml5235
drwxr-xr-x 2 admin root 16384 Apr 9 09:52 ml5236
drwxr-xr-x 2 admin root 0 Jun 23 2019 ml5241
drwxr-xr-x 2 admin root 0 Jul 17 2020 ml5242
drwxr-xr-x 2 admin root 16384 Feb 17 2020 ml5243
drwxr-xr-x 2 admin root 16384 Feb 17 2020 ml5244
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5245
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5246
drwxr-xr-x 2 admin root 0 Jun 23 2019 ml5247
drwxr-xr-x 2 admin root 16384 Oct 7 2019 ml5248
drwxr-xr-x 2 admin root 0 Jun 20 2019 ml5250
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5251
drwxr-xr-x 2 admin root 16384 Sep 23 2020 ml5252
drwxr-xr-x 2 admin root 16384 Mar 24 14:44 ml5253
drwxr-xr-x 2 admin root 16384 Oct 7 2019 ml5255
drwxr-xr-x 2 admin root 16384 Oct 18 2019 ml5256
drwxr-xr-x 2 admin root 16384 Oct 1 2020 ml5257
drwxr-xr-x 2 admin root 16384 Sep 8 2020 ml5259
drwxr-xr-x 2 admin root 65536 Apr 8 12:59 ml5261
drwxr-xr-x 2 admin root 65536 Apr 8 12:59 ml5262
drwxr-xr-x 2 admin root 32768 Jan 22 11:52 ml5264
drwxr-xr-x 2 admin root 16384 Feb 17 2020 ml5265
drwxr-xr-x 2 admin root 16384 Mar 17 11:43 ml5266
drwxr-xr-x 2 admin root 0 Jun 23 2019 ml5267
drwxr-xr-x 2 admin root 16384 Oct 18 2019 ml5268
drwxr-xr-x 2 admin root 0 Jun 23 2019 ml5269
drwxr-xr-x 2 admin root 16384 Oct 18 2019 ml5270
drwxr-xr-x 2 admin root 0 Jun 23 2019 ml5271
drwxr-xr-x 2 admin root 16384 Jun 20 2019 ml5272
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5273
drwxr-xr-x 2 admin root 16384 Oct 1 2020 ml5274
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5275
drwxr-xr-x 2 admin root 16384 Sep 23 2020 ml5276
drwxr-xr-x 2 admin root 16384 Oct 7 2019 ml5277
drwxr-xr-x 2 admin root 16384 Jul 21 2020 ml5278
drwxr-xr-x 2 admin root 0 Jul 17 2020 ml5280
drwxr-xr-x 2 admin root 0 Jul 17 2020 ml5281
drwxr-xr-x 2 admin root 0 Jul 17 2020 ml5283
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5284
drwxr-xr-x 2 admin root 32768 Mar 2 17:28 ml5287
drwxr-xr-x 2 admin root 16384 Oct 18 2019 ml5289
drwxr-xr-x 2 admin root 16384 Feb 17 2020 ml5290
drwxr-xr-x 2 admin root 16384 Jul 21 2020 ml5293
drwxr-xr-x 2 admin root 16384 Oct 7 2019 ml5294
drwxr-xr-x 2 admin root 16384 Jun 21 2019 ml5295
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5297
drwxr-xr-x 2 admin root 0 Jul 17 2020 ml5301
drwxr-xr-x 2 admin root 16384 Jun 21 2019 ml5302
drwxr-xr-x 2 admin root 0 Jul 17 2020 ml5303
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5306
drwxr-xr-x 2 admin root 0 Jul 17 2020 ml5307
drwxr-xr-x 2 admin root 0 Jun 18 2019 ml5308
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5309
drwxr-xr-x 2 admin root 16384 Mar 25 15:50 ml5310
drwxr-xr-x 2 admin root 16384 Jun 20 2019 ml5312
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5313
drwxr-xr-x 2 admin root 16384 Jun 19 2019 ml5314
drwxr-xr-x 2 admin root 65536 Apr 8 12:59 ml5315
drwxr-xr-x 2 admin root 0 Jun 23 2019 ml5316
drwxr-xr-x 2 admin root 0 Aug 12 2020 ml5317
drwxr-xr-x 2 admin root 16384 Mar 16 2020 ml5318
drwxr-xr-x 2 admin root 0 Jun 23 2019 ml5319
drwxr-xr-x 2 admin root 0 Aug 12 2020 ml5320
drwxr-xr-x 2 admin root 0 Jul 17 2020 ml5321
drwxr-xr-x 2 admin root 16384 Oct 7 2019 ml5322
drwxr-xr-x 2 admin root 16384 Mar 24 14:44 ml5323
drwxr-xr-x 2 admin root 16384 Jun 21 2019 ml5324
drwxr-xr-x 2 admin root 65536 Apr 8 12:59 ml5325

[Timothy_Hall]

Hmm all those timers look correct.  SMB drive shares are normally handled in the Medium Path (PXL), can you find your SMB connection in the output of the fwaccel conns command?  There were new columns added to this command in R80.20+ that will help you diagnose how long the SMB connection has been up and when traffic was last passed through it:  

• New columns added to 'fwaccel conns':
  • Last seen - time passed since last packet on this connection
  • Duration – time passed since the connection was created
  • Total Bytes: total bytes passed on the connection since it was created
  • Total Pkts: total packets passed on the connection since it was created
• TTL/Timeout – now shows the real timeout (In previous versions it shows the timeout of the entry on the connection table and not real session timeout

This should help you determine how the firewall is handling the connection from an idle time perspective.  If you don't see the SMB connection at all in the output of this command the SMB connection is getting handled F2F, which is kind of unlikely (use command fw ctl multik gconn in this case). 

The connection timing rules are also slightly different for connections fully or partially handled by SecureXL, so another interesting thing to try would be disabling SecureXL for an IP address involved with the SMB share as mentioned here to make all that traffic go F2F and see if that impacts the issue:  sk104468: How to disable SecureXL for specific IP addresses  Not a permanent solution by any means, but will at least tell you if you are looking in the right place, which is 90% of effective troubleshooting.

[Dreyfuss]

I´ll try out about this and keep you informed. Thanks for your time.