Stop all of services and umount all of volumes

Step1: Stop all of services

/etc/init.d/services.sh stop

/etc/init.d/qsnapman.sh stop

/sbin/daemon_mgr lvmetad stop “/sbin/lvmetad” rm /var/run/lvm/lvmetad.socket

Step2: Confirm which volume group or pool need to repair

pvs # list all of volume groups

lvs -a # list all of volumespools and volume groups

lvs -o+time # can list the created date/time of volumespools lvs -o+thin_id # can list the devices id of volumes

Check Volume Groups using “pvs” command

PV VG Fmt Attr PSize PFree

/dev/drbd1 vg1 lvm2 a– 7.24t 0 # /dev/drbd1 indicates md1(RAID group 1)

/dev/drbd2 vg2 lvm2 a– 7.26t 0 # /dev/drbd2 indicates md1(RAID group 2)

.

.

.

# One Volume Group may include >= 2 RAID groups

Check devices on the volume group/pool which we need to repair using “lvs -a” command

Step3: Assume vg1 need to repair, we need to umount the volumes which belong to the vg1(lv1 will be mounted in /share/CACHEDEV1_DATA….. and so on….)

If there is any volumes or snapshots which is mounted and the mounted volumes belong to the volume group which need to repair, please umount them

# below umount all of data volumes umount /share/CACHEDEV1_DATA

umount /share/CACHEDEV2_DATA

.

.

umount /share/CACHEDEV${#}_DATA

# below umount snapshots umount /dev/mapper/vg1-snap*

if can not umount, lsof /share/CACHEDEV{#}_DATA to check, and “kill -9” these process. Try to umount the volumes again.

Remove all of cache devices and inactivate volume group

Step1: You can list which cache devices on the pool:

ls -l /dev/mapper/ # will list all of devices on the pool

Step2: The result of the above command looks like below(below assume vg1 is the volume group which need to repair)

Step3: Find cachedev${#} and remove them using dmsetup

dmsetup remove cachedev1 dmsetup remove cachedev2

.

.

.

dmsetup remove cachedev${#}

Step4: Inactivate the volume group which need to repair

lvchange -an vg1 # Assume vg1 is the volume group which need to repair

Step5: Please check again with “ls -l /dev/mapper” command to confirm there is no any block device of vg1. The result should be the below:

crw——- 1 admin administrators 10, 236 2020-02-15 18:14 control

Collect logs of thin pool metadata and backup metadata of the thin pool

Step1: Download collect tools

wget http://download.qnap.com/Storage/tsd/utility/tp_collect.sh

Step2: Execute collect tools to collect logs of the metadata or backup metadata of the pool

sh tp_collect.sh

When the tp_collect.sh start running, please remember enter “pool id”. The pool id is the id of the pool which we want to repair. For examples: vg1/tp1, please input 1vg2/tp2, please input 2……and so on…..

If execute tp_collect fail, you need to let the customer plug one USB external drive(about 100G or more) in the NAS to backup metadata

# assume vg1/tp1 need to collect or repair lvchange -ay vg1/tp1_tmeta

# Change directory to the USB external device cd /share/external/DEVXXXXXX

# backup metadata using dd command

dd if=/dev/mapper/vg1-tp1_tmeta of=tmeta.bin bs=1M

If tp_collect is executed completely or successfully, you can skip the above flow and please backup collect.tgz.

Step 3: Please confirm the backup of metadata is correct

# A. thin check original metadata

pdata_tools_8192(or 4096) thin_check /dev/mapper/vg1-tp1_tmeta

# B. thin check backup metadata

pdata_tools_8192(or 4096) thin_check /mnt/collect/tmeta.bin # If the metadata is backup in the USB external drive, please pdata_tools_8192(or 4096) thin_check /share/external/DEVXXXXXX/tmeta.bin

The result of the above A, B need to be the same. If the A, B is the same, Please be sure to backup the tmeta.bin to another storage or USB

external drive!!! If the vg{#}-tp{#} repaired fail, the vg{#}-tp{#}_tmeta can be restored using tmeta.bin.

• No Comments

Check metadata:

Please use thin_check to check the metadata of the pool to confirm what wrongs in the metadata.

pdata_tools_8192( or 4096) thin_check /dev/mapper/vg1-tp1_tmeta –non

# Assume the ghost snapshot happen in vg1/tp1. Please according to happened ghost snapshot pool to adjust vg${#}

-tp${#}_tmetadata

# if the firmware version of QTS is less than 4.3.5, please remove “–non” option

Generally, the metadata has the below wrong:

If the metadata has no such as above wrong, please contact sustain team to analyze.

Backup metadata before repairing the metadata:

Caution!!! This is very important task!!!

Please must make a backup of the metadata to avoid the repairing task fail.

If the repairing task fail, the storage may crash. We can use the backup metadata to restore the storage.

Please use the below guide to make the backup of metadata:

https://drive.google.com/file/d/14HSVV6DWSnqc7FXTSUukzJWB812Q8Tkv/view?usp=sharing

Repairing flow and limitations:

Limitations:

If the storage configuration and QTS firmware versions can not meet the following condition, please contact sustain team to do repairing task.

1. The QTS firmware version is great or equal than 4.3.5.

2. The chunk size of the metadata need to be 8192. Please use the below command to confirm.

echo $((16#`hexdump -s 340 -n 2 /dev/mapper/vg1-tp1_tmeta | awk ‘NR==1{print $2}’`*512))

Repairing steps:

Step 1: Download “pdata_tools” which support thin_rebuild option from the below link and transfer new “pdata_tools” to the NAS.

# Download

wget http://download.qnap.com/Storage/tsd/utility/pdata_tools_X86_64.zip # X86_64 version wget http://download.qnap.com/Storage/tsd/utility/pdata_tools_ARM_64.zip # ARM_64 version

# Unzip

unzip pdata_tools_X86_64.zip unzip pdata_tools_ARM_64.zip

# Please rename to pdata_tools

mv pdata_tools_X86_64 pdata_tools mv pdata_tools_ARM_64 pdata_tools

Step 2: Change “pdata_tools” to executable file.

chmod +x pdata_tools

Step 3: Run pdata_tools with thin_rebuild option.

./pdata_tools thin_rebuild /dev/mapper/vg1-tp1_tmeta # This process will execute about couple minutes or hours. Please wait for the process done patiently.

Step 4: Use thin_check to check metadata again to confirm the “reference counts” wrongs are all fixed. If the result of thin_check still has wrongs, please contact sustain team to do the repairing task.

./pdata_tools thin_check –clear-needs-check-flag /dev/mapper/vg1-tp1_tmeta

Step 5: Restore the storage:

lvchange -ay vg1 # bring up the volume group storage_util –sys_startup_p2 # mount all of volumes

/sbin/daemon_mgr lvmetad start “/sbin/lvmetad” # enable lvm cache

/etc/init.d/services.sh start # start up all of services

• No Comments

Recently was trying to disable access to a subfolder on an IIS site. Adding IP Restrictions to the site , and looking the Logs , the address of the requestor was coming up as the Gateway of the DMZ.

We need to use the X-forwarder-For header for this , however a need a WAF or application level firewall to do this stamping for us

After enabling Proxy Mode on Cloudflare for the hostname , the correct IP address starting populating for X-forwarder-For header so I could turn on blocking

• No Comments

1. I recommending backing up the Autocomplete from both Accounts via Backing up and restoring the AutoComplete cache of Outlook 2010, 2013, 2016, 2019 and Office 365 – MSOutlook.info
2. Login to account you would like to copy the autocomplete from in Outlook , it will create a C:\Users\%username%\AppData\Local\Microsoft\Outlook\RoamCache\Stream_Autocomplete_0_XXXXXXXXXX1.dat file
3. You can use nk2 editor to read this if you want to confirm http://www.nirsoft.net/utils/outlook_nk2_edit.html 
4. Login to the account you would like to copy the to , it will create a C:\Users\%username%\AppData\Local\Microsoft\Outlook\RoamCache\Stream_Autocomplete_0_XXXXXXXXXX2.dat file
5. Cloud outlook and rename Stream_Autocomplete_0_XXXXXXXXXX2.dat to Stream_Autocomplete_0_XXXXXXXXXX2.datold and rename Stream_Autocomplete_0_XXXXXXXXXX1.dat to Stream_Autocomplete_0_XXXXXXXXXX2.dat. 
6. Reopen outlook
7. Add a new contact that’s not in your autocomplete e.g. test@test.com and send an email
8. Close Outlook and reopen it
9. It should merge your old Autocomplete with your existing one

• No Comments

Make sure the Netscaler has a correct SNIP IP Address that can ping the DNS server , pinging from the Netscaler IP wont work 

• No Comments

Recently a wordpress site crashed after with the error : 

[pid 31317] PHP Fatal error: Uncaught Error: Cannot call constructor in /wp-content/plugins/woocommerce-services/classes/wc-api-dev/class-wc-rest-dev-data-continents-controller.php:47\nStack trace:\n#0 wp-content/plugins/woocommerce-services/woocommerce-services.php(922): WC_REST_Dev_Data_Continents_Controller->__construct()\n#1 wp-includes/class-wp-hook.php(287): WC_Connect_Loader->wc_api_dev_init(Object(WP_REST_Server))\n#2 
wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters(NULL, Array)\n#3 
wp-includes/plugin.php(478): WP_Hook->do_action(Array)\n#4 wp-includes/rest-api.php(506): do_action('rest_api_init', Object(WP_REST_Server))\n#5

/wp-content/plugins/disable-json-api/classes/helpers.php(10): rest_get_server()\n#6 wp-content/plugins/disable-json-api/classes/helpers.php(36): DRA_Helpers::get_all_rest_routes()\n#7  in wp-content/plugins/woocommerce-services/classes/wc-api-dev/class-wc-rest-dev-data-continents-controller.php on line 47, referer: wp-cron.php?doing_wp_cron

Disabling the woocommerce-services Plugin stopped the error showing

Upgrading Woo-Commerce to version 5.0.0 then re-enabling woocommerce-services Plugin fixed the issue

• No Comments

Create vlan "ISOLATED"
configure vlan ISOLATED description "ISOLATED"
Configure vlan ISOLATED tag 200
conf vlan ISOLATED add port 2:14 tagged

Remove

"configure vlan <vlan name> delete ports <port_list>".

• No Comments

when enabling DDOS, UTM or traffic over VPN. I believe this applies to other video solutions like zoom.

Workarounds below:

https://kb.fortinet.com/kb/documentLink.do?externalID=FD50610

For any voice-type traffic you should not use UTM at all.

You can use Internet Service as destination to capture the traffic to teams/zoom etc

• No Comments

use the ‘log off when inactive timer’ 

Computer configuration > Policies > Administrative template > Windows component > Remote Desktop services > remote desktop session host > session time limits > Set to 8 hours from 1day

Application Configuration

Select user mode policies> edit Unfiltered policy in citrix Policies>

>Disconnected Session Timer enabled

>Disconnected Session Timer interval 300mins

• No Comments

Webroot has received reports of symptoms similar to those that you have reported. As a temporary measure there are two options for alleviating this issue.

First:

If you are utilizing the Task Scheduler for the backups to be performed (This can be seen in the system-Scheduled_Tasks.csv or Task Scheduler in Windows).

Example : C:\Windows\system32\vssadmin.exe Create Shadow /AutoRetry=15 /For=\\?\Volume{f3eeccd1-6c54-43d9-b19e-6695945f7934}

This command can be replaced with the following instead : wmic shadowcopy call create Volume=c:\

(Volume letter depends on the corresponding volume id they are attempting to copy)

Second:

If Task Scheduler is not being employed, we would like you to disable some settings within your Webroot policy which has been successful in alleviating the issue.

1. Log into your Webroot console.

2. Click on the Policies tab then the policy we will be modifying

3. Under Policy Section select Local Heuristics

a. Set Enable Infrared to “Off”

b. Click the Save button

4. Under Policy Section select Network Heuristics

a. Set Advanced Heuristics to “Disabled”

b. Click the Save button

* All endpoints assigned to this policy will update within 24hrs depending on the configured poll interval.

• No Comments