Section 11.1.3, Windows Explorer Hangs On Accessing the CIFS Share Path
Section 11.1.4, Salvaged Files are not Displayed in Windows 7 Enterprise Client
Section 11.1.10, Windows Clients Do Not Reflect The Latest File/Folder Operations
Section 11.1.11, Different Tree Migration Is Not Available in the Migration Tool
Section 11.1.12, File Level Trustees Are Deleted When a File is Modified
Cause: CIFS service configured with service proxy fails to come up after upgrading to OES 2018 or later. This is because the service proxy users are not migrated to OES Credential Store (OCS).
Action: To resolve this issue, perform the following:
Login as root user.
Run yast2 novell-cifs and then enter eDirectory user password.
Specify the CIFS proxy user password.
Click Next and continue with CIFS configuration.
Verify the CIFS service is up and running by using the following command:
systemctl status novell-cifs.service
Verify the service entry is present in OES Credential Store by using the following command:
oescredstore -l
Description: If you change the server dialect from SMB2 or later to SMB, the Windows client with the existing mapped share might not establish connection automatically.
Also, in a mixed-node cluster environment, if you migrate a cluster resource from OES 2015 or later node configured with SMB2 or later to earlier versions of OES or nodes configured with SMB, the existing connections accessing that resource might not establish automatically.
Cause: The client maintains a runtime cache for each server with which it communicates, whose cached entry indicates the dialect supported by the server.
When the share is on the server configured with SMB2 or later dialect, the client maps the share using that dialect. Even after the server dialect is changed to SMB, the client still attempts to reconnect using SMB2 or later, which the server rejects.
Similarly, when a cluster resource is on an OES 2015 or later node with SMB2 or later, the client maps the resource using that dialect. If the same resource is migrated to nodes with SMB, the client assumes that this server is also SMB2 or later dialect capable and without negotiating with the server attempts to reconnect using SMB2 or later, which the node rejects as it is not SMB2 or later dialect capable.
Action: To resolve this problem, the user must manually disconnect the share and map it again. When doing a fresh mapping, the client first enumerates and negotiates the capability of the server and then connects using the highest dialect that the server is capable of.
Cause:
If the CIFS share path (path to the volume or root directory of the sharepoint) contains millions of objects and you are accessing the shared path using the Windows Explorer, it hangs.
If a subdirectory inside the CIFS share path contains millions of objects and you are accessing the shared path using Windows Explorer, it hangs as you approach the subdirectory containing millions of objects.
Action: To resolve this issue, ensure that the CIFS share path or any subdirectory inside the CIFS share path does not contain millions of objects.
Cause: This is due to cache refresh issue in Windows CIFS client. For more information, see https://support.microsoft.com/en-in/kb/2646563.
Action: To view the salvaged files, do the following in Windows Explorer:
Refresh or
Perform any file I/O operation.
Even though manual synchronization is enabled, the offline files and folders on the Windows clients automatically synchronize with the OES server the next time the clients are connected to the network.
Micro Focus has no plans to fix this issue, because this issue pertains to the functionality of the Windows clients.
Description: If the ad-supervisor-group in NIT is changed from the default group "Domain Admins" to a custom-created group, the effective rights of the members of the default group "Domain Admins" is displayed as NULL. However, those users are able to successfully map and perform administrative activities on those AD-enabled NSS volumes from a CIFS client.
Cause: Modification of ad-supervisor-group do not take effect across subsystems until SEV refresh is performed.
Action: Force the SEV update to occur immediately for all users in the NSS file system by running the nss /ForceSecurityEquivalenceUpdate command at the nsscon prompt.
IMPORTANT:You have to perform this action on all the servers where you have changed ad-supervisor-group using the nitconfig set ad-supervisor-group=<group_name> command.
Now, verify the Effective Rights of the members of the Domain Admins group. It must display as NULL and those users shouldn't be able to map AD-enabled NSS volumes and perform administrative activities.
Users are not able to map NSS resources shared with them from Windows Explorer.
Mapping might fail for the following reasons:
No DNS reverse lookup zone (IPv4 and IPv6) exists for the Active Directory server.
No DNS entry exists for the OES server.
Ping the OES server to see if it is reachable.
Do an nslookup for the OES server. An NXDOMAIN error might be returned.
Create a Host(A) record in the applicable forward lookup zone for the OES server.
Running the nslookup or dig commands must return successful results.
No DNS entry exists for the OES NSS pool cluster resource.
Ping the OES NSS pool cluster resource to see if it is reachable.
Do an nslookup for the OES NSS pool cluster resource. An NXDOMAIN error might be returned.
Create a Host(A) record with the NetBIOS name of the cluster resource in the applicable forward lookup zone.
Running the nslookup or dig commands must return successful results.
CIFS is not configured as the Advertising protocol while creating the cluster pool.
Create a cluster pool with CIFS as the Advertising protocol.
Neither the password policy nor Universal Password is set for the eDirectory user.
Using iManager, set the password policy (iManager > Passwords > Password Policies) and set the Universal Password (iManager > Passwords > Set Universal Password).
Check the /var/log/cifs/cifs.log file for more details.
The NSS resource is not exposed as a CIFS share.
Using iManager, expose the NSS resource as a CIFS share (iManager > File Protocols > CIFS > Shares).
Improper mapping of user rights.
Using NURM, remap the user rights.
From the server console, run any of the following commands to check the trustee rights for the volume or directory that you are trying to map.
rights -f /media/nss/VOLNAME show rights -f /media/nss/VOLNAME/DIRNAME show
Wrong user name or password.
The client from which the user is trying to map the shared resource is joined to the Windows domain, and the user exists in both directory services.
For example, the Windows client “win7client” is joined to the domain “acme.com” and the user “susanne” exists in both of the directory services. Susanne can share the same password in both directory services or can have different passwords.
Susanne is assigned as a trustee to the directory “/media/nss/VOL1/mktg.” Using iManager, the directory “mktg” is exposed as a CIFS share with the share name “marketing.”
Using NURM, the Administrator has mapped eDirectory user susanne’s rights to the Active Directory user susanne.
When susanne tries to map the shared resource, the Windows client will first attempt to authenticate the domain user “Susanne,” that is, “acme\susanne.” The client will expect Susanne to provide her Active Directory password. If the passwords are the same in both the directory services, the client will authenticate Susanne using the Active Directory password.
If Susanne specifically wants to map the resource using her eDirectory user credentials, then she can use either of the formats: “\username” or “treename\username” and provide her eDirectory password.
Active Directory User: Map the NSS resource by specifying the host name of the OES server, for example, \\eurus\marketing.
eDirectory User: Map the NSS resource by specifying the host name or IP address of the OES server, for example, \\eurus\marketing or \\192.168.100.10\marketing.
How to check whether the logged-in user is from Active Directory or eDirectory?
From the server console, run the novcifs -Cl command to view the connection details.
You can also view the CIFS connection list using OES Remote Manager (NRM) (Manage CIFS Services > Manage Connections).
Description: The CIFS service fails to write core dumps when it crashes.
Cause: Beginning with OES 2015, the setfsuid() system call is used to perform all file system operations with the user context.
The setfsuid() system call introduced in the CIFS daemon resets the process-specific dumpable setting to the system-wide setting kernel.suid_dumpable (default value is 0). Therefore, if kernel.suid_dumpable is not 2, it might affect the capability of the CIFS process in generating a core if it crashes.
Action: Enable the kernel to write core dumps by executing the command sysctl -w kernel.suid_dumpable=2.
For security reasons, core dumps in this mode are not overwritten. This mode is appropriate when administrators are attempting to debug problems.
To additionally make this configuration change persistent over reboots, add the line kernel.suid_dumpable=2 to the /etc/sysctl.conf configuration file.
Description: OES server fails to authenticate CIFS users if it is joined to a tree wherein a NetWare server holds the master or read/write replicas of CIFS users.
Cause: The NMAS method in OES Linux has been updated; however, it is not updated in NetWare.
Action: Move the master or read/write replicas of CIFS users from the NetWare server to an OES Linux server (OES 2 SP3, OES 11, OES 11 SP1, OES 11 SP2) before you join an OES 2018 or later server to the tree.
Description: Windows 7 and Windows 2008 R2 clients do not reflect the latest file or folder operations such as, create, rename, and salvage.
Cause: This issue is observed when the clients communicate with the server using SMB 2.002 or later protocol versions.
Action: To fix this issue, apply the hotfix available on the Microsoft Support web site.
Description: The Different Tree scenario is not supported in the Migration Tool.
Action: Use the following workaround:
Migrate the File System from the source server to the target server, using the Different Tree scenario.
For detailed information see, Migrating Data to a Server in a Different Tree
in the OES 2018 SP2: Migration Tool Administration Guide.
Reconfigure CIFS by using YaST on the target server.
For detailed YaST configuration steps, see Section 4.1, Installing CIFS during the OES Installation and Section 4.2, Installing CIFS after the OES Installation.
File level trustees might be deleted when a file is modified, depending on how the application works with files it opens for writing. Some third-party applications record changes in a temporary file in order to save internal memory or as a safety net to prevent data loss due to a power failure, system crash, or human error. When a user saves the changes, the application deletes the original file, and saves the temporary file with same name as the original file. In response to the deletion instruction, the file system deletes the original file as well as any file level trustees set on the file. The file system is not application aware; that is, it does not track the ultimate intent of the applications that you might use.
For more information, see File-Level Trustees
in the OES 2018: File Systems Management Guide.