11.1 Known issues

11.1.1 Interruption in access to the CIFS shares from Windows clients upon change of server dialect from SMB2 to SMB or upon cluster resource migration

Description: If you change the server dialect from SMB2 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 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 dialect, the client maps the share using SMB2 dialect. Even after the server dialect is changed to SMB, the client still attempts to reconnect using SMB2, which the server rejects.

Similarly, when a cluster resource is on an OES 2015 or later node with SMB2, the client maps the resource using SMB2 dialect. If the same resource is migrated to nodes with SMB, the client assumes that this server is also SMB2 dialect capable and without negotiating with the server attempts to reconnect using SMB2, which the node rejects as it is not SMB2 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.

11.1.2 Salvaged Files are not Displayed in Windows 7 Enterprise Client

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.

11.1.3 The Mount Command on SLED 12 does not Mount NSS Volumes of OES 2015 SP1 Server for AD users

Active Directory users are not able to authenticate from a SLED 12 box with SMB v1 or SMB v2. Therefore the mount command when executed from a SLED 12 machine fails and the AD users are not able to access NSS volumes even though they have sufficient rights to access them.

Novell has no plans to fix this issue, because this issue pertains to the functionality of the SLED 12 clients.

11.1.4 Automatic Synchronization of Offline Files

Even though manual synchronization is enabled, the offline files and folders on the Windows clients automatically synchronize with the OES 2015 SP1 server the next time the clients are connected to the network.

Novell has no plans to fix this issue, because this issue pertains to the functionality of the Windows clients.

11.1.5 Members Of The Default ad-supervisor-group "Domain Admins" Can Map AD-enabled NSS Volumes Although Their Effective Rights on Those Volumes Is Displayed As NULL

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 NIT and CIFS are restarted.

Action:

  1. Restart the NIT daemon by running the rcnovell-nit restart command at the terminal console.

  2. Restart the CIFS service by running the rcnovell-cifs restart command at the terminal console.

  3. 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 these actions 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.

11.1.6 Users Are Not Able to Map NSS Resources

Users are not able to map NSS resources shared with them from Windows Explorer.

Mapping might fail for the following reasons:

  1. No DNS reverse lookup zone (IPv4 and IPv6) exists for the Active Directory server.

  2. No DNS entry exists for the OES 2015 SP1 server.

    • Ping the OES 2015 SP1 server to see if it is reachable.

    • Do an nslookup for the OES 2015 SP1 server. An NXDOMAIN error might be returned.

    Create a Host(A) record in the applicable forward lookup zone for the OES 2015 SP1 server.

    Running the nslookup or dig commands must return successful results.

  3. No DNS entry exists for the OES 2015 SP1 NSS pool cluster resource.

    • Ping the OES 2015 SP1 NSS pool cluster resource to see if it is reachable.

    • Do an nslookup for the OES 2015 SP1 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.

  4. CIFS is not configured as the Advertising protocol while creating the cluster pool.

    Create a cluster pool with CIFS as the Advertising protocol.

  5. 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.

  6. 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).

  7. 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

  8. 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 2015 SP1 server, for example, \\eurus\marketing.

    eDirectory User: Map the NSS resource by specifying the host name or IP address of the OES 2015 SP1 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 Novell Remote Manager (Manage CIFS Services > Manage Connections).

11.1.7 Novell CIFS Fails to Write Core Dumps

Description: The Novell 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 in SLES 11 SP4). 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.

11.1.8 CIFS Users Unable to Authenticate to OES 2015 SP1 Server if the Tree has Netware server as the eDirectory Replica Holding Server

Description: OES 2015 SP1 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 2015 SP1 server to the tree.

11.1.9 Windows Clients Do Not Reflect The Latest File/Folder Operations

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.

11.1.10 CIFS Does Not Start If Samba is Running

Description: CIFS server does not come up if the Samba server is running.

Cause: Novell CIFS cannot coexist with Samba daemons as they both use the same port.

Action: Log in to the OES server as root. Use the following commands to stop the Samba daemons and restart the CIFS server:

  • rcsmb stop

  • rcnmb stop

  • rcnovell-cifs start

11.1.11 Different Tree Migration Is Not Available in the Migration Tool

Description: The Different Tree scenario is not supported in the Migration Tool.

Action: Use the following workaround:

  1. 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 2015 SP1: Migration Tool Administration Guide.

  2. 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.

11.1.12 File Level Trustees Are Deleted When a File is Modified

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 2015 SP1: File Systems Management Guide.