Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it! Learn more

  • State Not Answered
  • Replies replies
    6
  • Subscribers subscribers
    25
  • Views views
    463
  • Users 0 members are here
Related
Options

Linux binaries or scripts will NOT run from NSS volumes on OES23.4

Stuart Park

From an OES23.4 server (for example) "/usr/bin/ls" will execute.

If "ls" is copied to an NSS volume, it will not run:
"
# /media/nss/VOL201/opt/ls
-bash: /media/nss/VOL201/opt/ls: cannot execute binary file: Exec format error
"

strace output:
"
# strace /media/nss/VOL201/opt/ls
execve("/media/nss/VOL201/opt/ls", ["/media/nss/VOL201/opt/ls"], 0x7ffcdc7054f0 /* 51 vars */) = -1 ENOEXEC (Exec format error)
strace: exec: Exec format error
+++ exited with 1 +++
"


The same thing happens with a python or perl script on an NSS volume. However a bash script will run successfully.
All these tests run fine from an NSS volume on OES 2018 SP2 Update 10.

Raised as case 02806985. Backline Support can reproduce this issue.

Has anyone else noticed this or have an idea what's happening?

Parents
  • 0

    Just a thought here, could this be something sles15 related causing this behaviour.

  • 0 in reply to 

    This is for sure a problem with sles 15 or linux kernels 5.xx and above. NSS volumes are made visible to the linux kernel as a ncp filesystem via ncp2nss. And Linux kernels till 4.18 had ncp-support built into the kernel. The 5.xx kernels don't have ncp-support built into their kernel, so seemingly the connection from the kernel to the nss volume goes now over 2 connectors from OT - one from kernel to ncp and one from ncp to nss. And one of those is obviously broken.

    If you mount the nss volume via cifs on the OES server, linux binaries work well (and probably python scripts etc., too).

Reply
  • 0 in reply to 

    This is for sure a problem with sles 15 or linux kernels 5.xx and above. NSS volumes are made visible to the linux kernel as a ncp filesystem via ncp2nss. And Linux kernels till 4.18 had ncp-support built into the kernel. The 5.xx kernels don't have ncp-support built into their kernel, so seemingly the connection from the kernel to the nss volume goes now over 2 connectors from OT - one from kernel to ncp and one from ncp to nss. And one of those is obviously broken.

    If you mount the nss volume via cifs on the OES server, linux binaries work well (and probably python scripts etc., too).

Children
  • 0 in reply to 

    The latest updates seem to have resolved that issue at least with executable files. I tested after I updated one server up to date and could run executable files from nss-volumes.

  • 0   in reply to 

    This is a clarification:

    NSS volumes are made visible to the Linux kernel directly like any other (ext4/xfs/btrfs/...) Linux filesystem - not via the NCP filesystem or ncp2nss. Also the built-in-ncp-in-the-kernel had no role in making NSS visible to the Linux kernel.

    NSS plugs-in as yet another filesystem with the Linux kernel via the VFS (Virtual File System) interface of the Linux kernel.

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.