CIFS share created on Access Appliance 8.x version may not be accessible if all the virtual IPs are on a VLAN device
Problem
CIFS share created on Access Appliance 8.x version may not be accessible if all the virtual IPs are on a VLAN device
If you create a CIFS share on Access Appliance 8.x where all the virtual IPs are on a VLAN device, the CIFS share created may not be accessible. This occurs because a dedicated IP has not been specified to be used for the share.
This knowledge base article is being written to supplement the Access Appliance 8.x release notes of a specific known issue with CIFS shares while using VLAN tagged devices:
https://sort.veritas.com/doc_viewer/#/content?id=152271497-156214160-0%2Fv159913686-156214160
Error Message
The issue can be seen in two ways:
1. The ShareOptions for a particular share will show options that were not specified when creating the share:
Ex.
va800b> cifs share add cifsfs cifs rw,allow=cifsuserExporting CIFS filesystem : cifs ...Success.
va800b> cifs share showShareName FileSystem ShareOptions
========= ========== =============================================================================================
cifs cifsfs owner=root,group=root,fs_mode=1777,allow=cifsuser,rw,msdfs root = yes,msdfs proxy = \\_cifs$\
msdfs root = yes, msdfs proxy = \\_sharename$\ are not valid CIFS options and are appearing due to the CIFS script logic parsing the arguments incorrectly when there are no free VLAN devices.
2. In the "cifs_share_add.log" from the node running the ManagementConsole service group, we can see the errors in the script logic.
Access 8.0/8.1: /log/VRTSnas/log/cifs_share_add.log
Access 8.2: /log/VRTSnas/cifs_share_add.log
...
2024-05-29T12:57:24.00-0700 TRACE (8648) cifs_lib.sh:600 : for vipgroup in '$vipgrouplist'
22024-05-29T12:57:24.00-0700 TRACE (8648) cifs_lib.sh:602 : hares -value VIP1 Device
2024-05-29T12:57:24.00-0700 TRACE (8648) cifs_lib.sh:602 : device=eth4.100
2024-05-29T12:57:24.00-0700 TRACE (8648) cifs_lib.sh:603 : is_vlan_device eth4.100
2024-05-29T12:57:24.00-0700 TRACE (8648) support_lib.sh:6798: '[' -z eth4.100 ']'
2024-05-29T12:57:24.00-0700 TRACE (8648) support_lib.sh:6800: echo eth4.100
2024-05-29T12:57:24.00-0700 TRACE (8648) support_lib.sh:6800: grep '\.'
2024-05-29T12:57:24.00-0700 TRACE (8648) support_lib.sh:6801: return 0
2024-05-29T12:57:24.00-0700 TRACE (8648) cifs_lib.sh:603 : '[' 0 -eq 0 ']'
2024-05-29T12:57:24.00-0700 TRACE (8648) cifs_lib.sh:603 : continue
2024-05-29T12:57:24.00-0700 TRACE (8648) cifs_lib.sh:617 : VIPGrpForNewShare=
2024-05-29T12:57:24.00-0700 TRACE (8648) cifs_lib.sh:618 : '[' '!=' '' ']'
/opt/VRTSnas/scripts/lib/cifs_lib.sh: line 618: [: !=: unary operator expected
2024-05-29T12:57:24.00-0700 TRACE (8648) cifs_lib.sh:622 : VIPForNewShare=
The argument of VIPGrpForNewShare returns an empty value as there are no free virtual IPs left to assign to the CIFS service.
The created share will likely be inaccessible to clients as the share options are invalid.
Cause
For this situation to occur, you must have all of the virtual IPs associated to the data network links VLAN-tagged, and also assigned to at least one service. There are no free (unused) VIPs.
va800b> network ip addr showIP Netmask/Prefix Device Node Type Status FQDNs
-- -------------- ------ ---- ---- ------ -----
192.168.10.150 255.255.255.0 eth4 va800b-01 Physical
192.168.10.152 255.255.255.0 eth5 va800b-01 Physical
192.168.10.122 255.255.255.0 eth1 va800b-01 Physical
192.168.10.151 255.255.255.0 eth4 va800b-02 Physical
192.168.10.153 255.255.255.0 eth5 va800b-02 Physical
192.168.10.123 255.255.255.0 eth1 va800b-02 Physical
192.168.10.125 255.255.255.0 eth1 va800b-02 Virtual ONLINE (Con IP)
192.168.10.160 255.255.255.0 eth4.100 va800b-01 Virtual ONLINE
va800b> nfs share showShareName Path Clients(options + ipbind)
========= ========== =========================
datafs /vx/datafs * (rw,no_root_squash)
In this cluster, NFS is also enabled and sharing a filesystem over this virtual IP. Other configured services could include Veritas Data Deduplication (VDD/MSDP), S3, NetBackup client, etc.
Solution
To workaround this issue, you can define a specific IP in the share name or ShareOptions when creating the share:
1. Delete the share (if it exists) - this will just unshare the file system, this does not change or affect the data within the filesystem.
> cifs share delete <filesystem>
ex.
va800b> cifs share delete cifsUnexporting CIFS share : cifs ....Access Appliance cifs ERROR V-493-10-5580 Internal Error occurred.
The Internal error message can be safely ignored.
va800b> cifs share showShareName FileSystem ShareOptions
========= ========== ============
2. Create the CIFS share by specifying the IP in either the share name or the share options:
a. Using sharename:
> cifs share add <filesystem> <share>@<virtual ip> <comma separated share options>
va800b> cifs share add cifsfs cifs@192.168.10.160 rw,allow=cifsuserExporting CIFS filesystem : cifs@192.168.10.160 ...Success.
va800b> cifs share showShareName FileSystem ShareOptions
=================== ========== ====================================================
cifs@192.168.10.160 cifsfs owner=root,group=root,fs_mode=1777,allow=cifsuser,rw
b. Using share options:
> cifs share add <filesystem> <share> ip=<virtual ip>,<other comma separated share options>
va800b> cifs share add cifsfs cifs rw,allow=cifsuser,ip=192.168.10.160Exporting CIFS filesystem : cifs ...Success.
va800b> cifs share showShareName FileSystem ShareOptions
========= ========== ====================================================
cifs cifsfs owner=root,group=root,fs_mode=1777,allow=cifsuser,rw
With option A, you'll note the IP is specifically noted in the share name, but with option B, it may not be clear which IP the share is associated with. You can view the details of the share with: > cifs share show <share name>
va800b> cifs share show cifsShareName VIP Address
========= ==============
cifs 192.168.10.160
ShareName va800b-01 va800b-02
========= ========= =========
cifs ONLINE ONLINE