When connecting an NVR running Ubuntu 12.04 or older to a newer S-series you may have issues with it connecting and displaying the “Disconnected” message on the archiving page; even thou everything is correct and systems running Ubuntu 14.04 or newer DO NOT have this issue.
When you search the logs, you will see a message stating it failed to connect.
There is a combination of configuration defaults that prevent an Ubuntu 12.04 server (or older) establishing an SMB connection to an Ubuntu 18.04+ (S-Series) server.
Samba changed their “allow ntlm” default from yes to no in version 4.5.0 The version of Samba available for Ubuntu 16.04 is 4.3.11 (still allows ntlm, no connection issue), and Ubuntu 18.04 is 4.7.6 (does not allow ntlm by default, so can’t connect).
The workaround used at the customer is to re-allow ntlm on the S-Series by adding ntlm auth = yes to the /etc/samba/smb.conf on the S-Series server and restarting smbd service.
You will need to either be right on the S-series or SSH in to it.
Run the following command in terminal from the S-series
sudo nano /etc/samba/smb.conf
Add the following in to it right above domains….. ntlm auth = yes
Make sure you save it when finished.
Next, restart the SMB service…
From terminal type the following sudo /etc/init.d/samba restart
Now, go back in to the Exacq Client>Archiving and disable archiving and re-enable it and it should connect.
Archiving must be done to a network resource that supports the hosting of SMB shares. By default, S-Series storage systems built by Exacq come with Samba installed. The following steps will need to be performed on a third-party Ubuntu system used in place of an ExacqVision S-Series system.
If you are using a software-only install on your own device running off-the-shelf Ubuntu Linux, you will first need to install/update Samba with the following commands in Terminal:
Samba uses its own credentials, separate from those of the OS user. This Samba user account must also exist as an OS user account. If you do not already have an OS user account you wish to use, create an OS user account with command below. If you do already have an OS user you wish to use for this, you may skip to Step 3.
sudo useradd username
Now set this user’s OS password with the following:
sudo passwd username
After entering the command, you will be prompted to enter a password, then re-enter the password to confirm. Remember, in Linux, passwords do not appear as you type.
<br>
You will need to create a username and set the user password for Samba. The ‘-a‘ parameter in the command below creates the Samba user account.
sudo smbpasswd -a username
After entering the command above, you will be prompted to enter a password, then re-enter the password to confirm. Remember, in Linux, passwords do not appear as you type.
<br>
Next, create the directory to be shared. This is where your archived video will be placed.
Using the command above, if you wanted to place a folder called VideoArchive in your admin home directory, the command would be sudo mkdir /home/admin/VideoArchive.
<br>
Change the permissions to the directory you just created to allow files to be written to it.
Scroll to the end of the file and add the following lines:
[<foldername>] path = /home/<username>/<foldername> valid users = <username> read only = no
You will replace ‘<foldername>‘ with that of the directory you created in Step 4 and replace ‘<username>‘ with the user created in Step 3.
Press CTRL-X to exit the nano editor. It will ask if you want to overwrite the existing file, enter y and press Enter to return to the Terminal prompt.
<br>
Restart Samba:
sudo service smbd restart
<br>
Preparing a Third-Party Client System
From the perspective of the SMB server, your recording ExacqVision NVR, where the ExacqVision Server software resides, acts as the SMB client. Therefore, if your recording NVR is also a third-party Ubuntu system, rather than one built-by Exacq, you will need to perform the following steps.
Open a Terminal window and enter each of the following commands:
In the ExacqVision Client navigate to the Archive Settings page.
Press the New button, then enter the Address of the share and the username and password you created earlier. The address will be the share path, i.e. – \\StorageIPaddress\foldername
Press the Apply button to connect to the share, then configure your Task Schedule.
NOTE: Archiving is a 1:1 relationship. Only one NVR may archive to a share. For multiple NVRs you will need multiple SMB archive targets.
Linux-based exacqVision servers could reboot frequently in certain conditions:
Linux operating system
Active hardware monitoring
Archiving over a slow network (WAN or other network with limited resources)
This issue was fixed in version 6.3.33.65575, and it is available in public release 6.4.
To work around this issue in affected versions, complete the following steps to configure an archiving SMB share:
In exacqVision Client, delete the currently enabled archive task. DO NOT disable the archive target.
Open the /etc/fstab file on the server for editing.
Locate the line with mount paths for the archive target.
Add a flag to the comma-separated section of the line specifying other flags (normally, this should immediately follow rw). The flag added depends on the Linux kernel version used:
Linux kernel 3.0-3.1 (archiving performance will be impacted)
Via shell terminal, execute umount [share path]. For example:
sudo umount /mnt/10.16.2.4.disk1
Via shell terminal, execute sudo mount -a.
Verify that step 5 was implemented correctly by executing cat /proc/mounts in the shell terminal and locating the line corresponding to the share (such as “directio” if you used the forcedirectio option for kernel 3.0-3.1).
In exacqVision Client, re-create the archive task.
Archiving from a Linux-based exacqVision system over a wide-area network (WAN) can stall in a Writing Files status for over an hour. If you believe a system is affected, verify the following conditions and symptoms:
Linux kernel version 3.0 or later. Previous versions are not believed to be affected. (To determine the kernel version, run uname -r in the shell of the server.)
The archive connection to the target is over a WAN in which disconnects are possible.
The archive task status has not been updated in more than one hour. (In exacqVision 6.6 and later, the Status section on the Archiving page displays a State of “Failed — Target File Write Stalled.”)
The currently archived file is not increasing in size. (To determine this, click on the details on the Archive page, note the Last Copied Content value, and navigate to the path of that content on the archive target. Verify whether the .workingps file is increasing in size periodically.)
<br>
This issue can be minimized by enabling strict caching mode and changing the cifs_max_pending cifs module parameter to 2 for Linux kernel 3.2 and later. To do this, complete the following steps:
Open the /etc/fstab file on the server for editing.
Locate the line with mount paths for the archive target.
Add a flag to the comma-separated section of the line specifying other flags (normally, this should immediately follow rw). The flag added depends on the Linux kernel version used:
Linux kernel 3.2-3.7 (archiving performance will NOT be impacted if oplocks are supported on the archive target):
Via shell terminal, execute umount [share path]. For example:
sudo umount /mnt/10.16.2.4.disk1
Via shell terminal, execute sudo mount -a.
Disable all archive targets (do not delete them).
Stop using any other cifs mounts on the system.
Unmount all cifs mounts using umount [path].
Create a file named /etc/modprobe.d/cifs.conf with a line options cifs cifs_max_pending=2 (this persists the value across restarts).
Unload the cifs module using sudo rmmod cifs.
Reload cifs with a new parameter: sudo modprobe cifs cifs_max_pending=2.
Verify the new value using cat /sys/module/cifs/parameters/cifs_max_pending.
Enable the archive targets.
Remount all other cifs shares.
<br>
If this procedure does not resolve the stalling issue, disable cifs client-side caching (this will impact archiving performance). You can try this in one of two ways:
Open the /etc/fstab file on the server for editing.
Locate the line with mount paths for the archive target.
Add a flag to the comma-separated section of the line specifying other flags (normally, this should immediately follow rw). The flag added depends on the Linux kernel version used:
Linux kernel 3.2-3.7 (archiving performance will NOT be impacted if oplocks are supported on the archive target):
Alternatively, you can enable strict caching mode on kernel 3.2 and later and also disable oplocks on the archive target. (NOTE: Strict caching mode is enabled automatically in exacqVision Server 6.6 and later.)
<br>
If you are using an exacqVision S-Series server (or other Samba-based server), oplocks can be disabled globally for all shares, or per share by adding the following lines to the appropriate section of the /etc/samba/smb.conf file:
oplocks=no level2 oplocks=no
<br>
NOTE: If your environment’s configuration cannot tolerate the performance implications of disabled SMB caching (see above), you can use NFS protocol for archiving instead of SMB. Be aware that there is no username and password protection with the NFS option. Use this Knowledge Base article to configure NFS archiving.
Archiving using NFS protocol instead of SMB protocol is possible starting with exacqVision Server 6.9.11 and exacqVision Client 6.9.14. However, the following steps might be required to enable NFS archiving functionality.
NOTE: Existing archive target configurations cannot be changed to use NFS. In those cases, a new archive target configuration must be created.
Linux
Install the nfs-common package with sudo apt-get install nfs-common
Restart evServer daemon with sudo service edvrserver restart
Use 6.7.x.x exacqVision Client to configure the NFS share. The share name MUST immediately follow the archive target IP/Hostname. This means that the NFS share name might have to be exported at the root / of the NFS server.
Windows
Windows XP:
NFS client is not supported.
Windows 7 Embedded / Enterprise/ Windows 7 Professional:
Use the legacy control panel. Open Start Menu and start typing “control” to find and click it.
Control Panel => Programs and Features => Turn Windows features on or off.
Check “Services for NFS” and click OK (includes both admin tools and Client for NFS).
Video is not recording to customers iSCSI targets after a reboot. Drive was reporting a status of “Recording Not Possible” on exacqVision Server 21.03.10. Servers running exacqVision Server version 20.06 or older were showing a status of healthy, but were not recording.
Identification
Use the following to properly identify the issue before applying the fix.
Update to exacqVision Server version 21.03 or later.
Check the drives status on the storage page.
If the status is “Recording Not Possible”
Enable debug level logging
Restart the exacqVision Server service
Monitor for log entries similar to those listed below, specifically Store Fails and GRV Fails
Check Extended Storage or Enterprise Storage for conflicting entries like those displayed below.
Once positively identified follow the steps outlined in the resolution section
Log files (debug level enabled)
Before Fix
After Fix
Enterprise Storage page was showing the Type as Local (iSCSI) on the servers which were not recording. Servers which were recording report the volume type as Local. Note: The server showing the Status of “Recording Not Possible” was running newer exacqVision Server software 21.03.10 vs 20.06 or older for the others.
Another indication was that the iSCSI targets populated both the Targets and Partitions Section of the Storage page, Extended tab. Whereas the servers which were recording normally populated only the iSCSI Targets.section
Resolution
rename archivepi.xml
rename psfpi.xml
restart exacqVision Server Service
Verify that storage targets are only listed in the Partition section of the Storage page (Configuration > Storage > Extended Tab)
Verify that the volume now has a type of Local on the Enterprise Storage page (Configuration > Enterprise > Storage)
exacqVision 7.1.23 to 7.2.0 running on Ubuntu Linux
<br>
Symptom
If the recorder is archiving and cannot reach an SMB archive target, the recorder will become unresponsive and watchdog reset.
<br>
Workaround
Downgrade to a version prior to 7.1.23
<br>
Resolution
Upgrade server to 7.2.1 or newer to address proper timeout detection and erroneous watchdog behavior. However, LDAP, e-mail notifications, drive/RAID monitoring and other operations involving external executable utilities will cease to function until the archive connection is restored. Refer to https://crm.exacq.com/kb/?crc=1151 for more details on how to subsequently resolve the archiving connection issue.
The Status of the Direct Search section on the Archiving page shows “Invalid username or password” However the target can be accessed through a file explorer and direct search can find video only present on the archive target and play it back.
While only cosmetic this issue can cause unnecessary concern and confusion and has been present since at least exacqVision Server Version 19.03
exacqVision’s default method for archiving recorded data uses the SMB protocol. Using an exacqVision S-Series storage system makes configuring archiving simple. Users may also archive to SMB shares configured on their own third-party systems, but installing and configuring Samba or SMB Shares on non-Exacq built systems is outside the scope of Exacq Support.
There have been several iterations of SMB since the protocol was first introduced. Devices wishing to communicate via SMB must first perform a negotiation to determine which version they will use. The version and dialect of SMB chosen will determine what features are used.
<br><br>
Versions
Discussing versions quickly becomes a tangled web, which we will try to unravel here.
When capturing the network traffic between two devices, using applications such as Wireshark, the protocol will be listed as SMB2, which supports many dialects including 2.1, 3.0, 3.1, which can cause some confusion as many people will refer dialects as versions. We will be using the term dialect for these here.
Introduced in 2015, dialect 3.1.1 is the latest release of SMB at the moment. While SMB is the protocol used, SMB is implemented on Linux systems using an application named Samba. Samba provides support for SMB as well as other protocols, thus it has it’s own version numbering separate from SMB. Samba has supported SMB dialect 3.1.1 since Samba 4.3.
How to check the version of Samba installed on your S-series or other Linux system:
Open a Terminal window, by pressing CTRL+ALT+T
Type samba --version, and press Enter.
<br><br>
Server Signing
Server signing is a security method used by SMB. When signing is enabled, every SMB message includes a signature key and a hash of the entire message is included in the message header.
How does signing help protect data? In addition to verifying the identities of the sending and receiving devices, the nature of hashing means that if an attacker changes the message between the NVR and the archive share, the hash will no longer match.
<br><br>
Encryption
SMB version 2.0 provides encryption, but used HMAC-SHA256 encryption. SMB 3.0 updated the encryption used to AES-CMAC and AES-CCM. SMB 3.1.1 then updated to support AES-128-GCM and AES-128-CCM as well as other security enhancements.
SMB Dialect
Encryption Method
2.0
HMAC-SHA256
3.0
AES-CMAC and AES-CCM
3.1.1
AES-128-GCM and AES-128-CCM
<br><br>
Manual Enforcement
As mentioned above, when two devices attempt to communicate using SMB they first negotiate the connection to determine the version and dialect they will use.
The client first advertises to the server which versions and dialects it supports. The server replies with the highest version and dialect it supports so they can agree. In the case of exacqVision’s Archiving, the client is the recording NVR system and the server is the S-Series system.
IMPORTANT: Because the protocol automatically selects the highest version both devices support, and because SMB signing and encryption are mature technologies, there is usually no need to manually configure settings. It is recommended only in situations where specific network requirements must be enforced to function properly.
<br>
To manually configure SMB:
On the S-Series server, open a Terminal window by pressing CTRL+ALT+T
Use sudo permissions to edit /etc/samba/smb.conf
Locate the [global] settings section.
Beneath the [global] tag, add the following lines: server signing = mandatory server min protocol = SMB3_11 server max protocol = SMB3_11
Save your changes, then exit the file.
Restart Samba by entering sudo /etc/init.d/samba restart
The entries given for Step 4 above enforce server signing as well as SMB dialect 3.1.1. Attempts to connect with anything else would fail. A list of possible options for these three entries is given below.
server signing = [default, auto, mandatory, disabled]
server min protocol = [SMB2, SMB2_02, SMB2_10, SMB3, SMB3_00, SMB3_02, SMB3_11]
server max protocol = [SMB2, SMB2_02, SMB2_10, SMB3, SMB3_00, SMB3_02, SMB3_11]
Note: ‘server min protocol’ should be the same or lower than ‘server max protocol’. If these are different values the client and server must support a dialect in between these values. If these are the same value, they must support that specific dialect.
IMPORTANT: Without editing the configuration at all, the default behavior when these fields are excluded from the smb.conf file are the same as entering the following: server signing = auto server min protocol = SMB2_02 server max protocol = SMB3
