[Errno 2] No such file or directory: '/mnt3/ob10ef/usr/lib64/zlib-ng-compat/libz.so.1'

Brief description of the problem:

Persistent error when adding a SFTP share:
'FileNotFoundError: [Errno 2] No such file or directory: ‘/mnt3/user-name/usr/lib64/zlib-ng-compat/libz.so.1’

Just adding a SFTP share over the web UI returns with error.

Error Traceback provided on the Web-UI:

File "/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py", line 40, in _handle_excNAME="openSUSE Tumbleweed" # VERSION="20250704" ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20250704" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" # CPE 2.3 format, boo#1217921 CPE_NAME="cpe:2.3:o:opensuse:tumbleweed:20250704:*:*:*:*:*:*:*" #CPE 2.2 format #CPE_NAME="cpe:/o:opensuse:tumbleweed:20250704" BUG_REPORT_URL="https://bugzilla.opensuse.org" SUPPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org" DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed" LOGO="distributor-logo-Tumbleweed" eption yield File "/opt/rockstor/src/rockstor/storageadmin/views/sftp.py", line 81, in post rsync_for_sftp(chroot_loc) File "/opt/rockstor/src/rockstor/system/ssh.py", line 258, in rsync_for_sftp copy(lib, f"{chroot_loc}{lib}") File "/usr/lib64/python3.11/shutil.py", line 431, in copy copyfile(src, dst, follow_symlinks=follow_symlinks) File "/usr/lib64/python3.11/shutil.py", line 258, in copyfile with open(dst, 'wb') as fdst: ^^^^^^^^^^^^^^^ FileNotFoundError: [Errno 2] No such file or directory: '/mnt3/user-name/usr/lib64/zlib-ng-compat/libz.so.1'

Output: ls usr/lib64/zlib-ng-compat/:

localhost:~ # ls /usr/lib64/zlib-ng-compat/
libz.so.1 libz.so.1.3.1.zlib-ng

Output: ldd /usr/bin/rsync

localhost:~ # ldd /usr/bin/rsync
linux-vdso.so.1 (0x00007fab18a4c000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007fab189a2000)
libpopt.so.0 => /lib64/libpopt.so.0 (0x00007fab18993000)
liblz4.so.1 => /lib64/liblz4.so.1 (0x00007fab18969000)
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fab18884000)
libxxhash.so.0 => /lib64/libxxhash.so.0 (0x00007fab1887a000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007fab18200000)
libz.so.1 => /usr/lib64/zlib-ng-compat/libz.so.1 (0x00007fab181dc000)
libc.so.6 => /lib64/libc.so.6 (0x00007fab17e00000)
libjitterentropy.so.3 => /lib64/libjitterentropy.so.3 (0x00007fab1886d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fab18a4e000)

Output: ldd /usr/bin/bash

localhost:~ # ldd /bin/bash
linux-vdso.so.1 (0x00007f3847c4e000)
libreadline.so.8 => /lib64/libreadline.so.8 (0x00007f3847afb000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3847800000)
libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f3847aba000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3847c50000)

Output: tree /mnt3/user-name:

localhost:~ # tree /mnt3/user-name/
/mnt3/user-name/
├── lib
├── lib64
│ ├── ld-linux-x86-64.so.2
│ ├── libacl.so.1
│ ├── libcap.so.2
│ ├── libcrypto.so.3
│ ├── libc.so.6
│ ├── libjitterentropy.so.3
│ ├── liblz4.so.1
│ ├── libpcre2-8.so.0
│ ├── libpopt.so.0
│ ├── libreadline.so.8
│ ├── libselinux.so.1
│ ├── libtinfo.so.6
│ ├── libxxhash.so.0
│ └── libzstd.so.1
├── SFTP_
└── usr
---------├── bin
---------│ ├── bash
---------│ ├── ls
---------│ └── rsync
---------└── lib64

OS:

NAME=“openSUSE Tumbleweed”
VERSION=“20250704”
ID=“opensuse-tumbleweed”
ID_LIKE=“opensuse suse”
VERSION_ID=“20250704”
PRETTY_NAME=“openSUSE Tumbleweed”
CPE 2.3 format, boo#1217921
CPE_NAME=“cpe:2.3:o:opensuse:tumbleweed:20250704:::::::*”
CPE 2.2 format
CPE_NAME=“cpe:/o:opensuse:tumbleweed:20250704”

2 Likes

@fe10, welcome to the Rockstor community.

Are you running Rockstor on top of a TW installation, or did you install Rockstor using the specific TW iso.

The way this looks you’re using zlib compression at least on the share or the pool and the share inherited it, can you confirm?

and this is also the first time you’re creating an sftp share for that user? I’m asking mostly because I’ve seen that once you remove an existing sftp share using the WebUI, it does not always seem to remove the /mnt3/user-name directory. and that could possibly lead to some conflicts when creating a new one at a later point in time.

I ran a quick test on a Leap 15.6 (version 5.1.0-0) instance, created a share, updated the owner/group to a non-root user and added the zlib compression algorithm (since the pool has a different one). Then creating the sftp share did not cause any issues.

Output: tree /mnt3/user-name:

/mnt3/user-name
├── lib
├── lib64
│   ├── ld-linux-x86-64.so.2
│   ├── libacl.so.1
│   ├── libattr.so.1
│   ├── libc.so.6
│   ├── libdl.so.2
│   ├── libpthread.so.0
│   ├── libreadline.so.7
│   └── libtinfo.so.6
├── sftp-test
└── usr
    ├── bin
    │   ├── bash
    │   ├── ls
    │   └── rsync
    └── lib64
        ├── libcap.so.2
        ├── libcrypto.so.3
        ├── libjitterentropy.so.3
        ├── liblz4.so.1
        ├── libpcre2-8.so.0
        ├── libpopt.so.0
        ├── libselinux.so.1
        ├── libslp.so.1
        ├── libz.so.1
        └── libzstd.so.1

And running

errors out because file cannot be found.

I also ran a test on a Rockstor instance running on TW (from the Rockstor install iso) on version 20250610, so a few weeks behind. I receive the same error:

            Traceback (most recent call last):
  File "/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py", line 40, in _handle_exception
    yield
  File "/opt/rockstor/src/rockstor/storageadmin/views/sftp.py", line 81, in post
    rsync_for_sftp(chroot_loc)
  File "/opt/rockstor/src/rockstor/system/ssh.py", line 258, in rsync_for_sftp
    copy(lib, f"{chroot_loc}{lib}")
  File "/usr/lib64/python3.11/shutil.py", line 431, in copy
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib64/python3.11/shutil.py", line 258, in copyfile
    with open(dst, 'wb') as fdst:
         ^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/mnt3/plex/usr/lib64/zlib-ng-compat/libz.so.1'

So, this is an additional confirmation that something is going array under TW. this was a newly installed instance that never had sftp shares created, so Rockstor correctly created the /mnt3/plex path.

I also attempted to do this without adding any compression algorithm to the underlying share, same result.

There is an open issue by @phillxnet on github:

due to other dev priorities and the focus on 15.6 for the stable release, this has not been addressed yet though. Not sure whether there is a good workaround using the WebUI, but is part of the plan for the next phase

2 Likes

Hello and thank you for the welcome,

As shown below, a screenshot of the two .iso that I used in the past.

For Context:
So i just made a quick test with 15.5 back a while. It worked fine with some errors here and there like when deleting a pool or a share, then I would just force delete them…
I made some shares, installed rock-ons: netBoot_xyz, jellyFin, piHole, espHome, homeAssistant. Managed to load the jellyfin media share over S FTP, worked fine played a little bit with it.

Problems with this S FTP [Errno 2] No such file or directory started after i did a fresh install and updated (quite a big list of updates… I may add), and … no success in exporting a share to S FTP. That was at least a week before May.18 as shown in the screenshot. I tried a couple of fresh installs (wiped my drives with windows “cipher /w:D”) still getting the same error. So i gave a up a bit…after a while… of being quite passive, noticed that 15.6 was available for download. I decided to start with a full wipe of my install drives, so shred -v the thing this time. Installed the 15.6 TW…and still the same.

So here i am. I’m glad I can help out a bit with the work you guys are doing.

cheers

1 Like

Yes, I think the underlying TW issues has existed for some months now, independent of the Rockstor version, so I am not surprised that you would run into the same problem between 5.015 and 5.1.0 as the situation had not changed (i.e. Rockstor did not address it in its coding, and the OpenSUSE TW distro didn’t change what they had already done).

So … if you really need something workable for sftp now, I would recommend to use the Leap 15.6 Rockstor 5.1.0 version for now. When this sftp issue has been fixed for the TW distro version, then you can simply backup your configuration, blow away the Rockstor OS disk, follow the re-installation procedure (including pool imports) and restore the configuration backup … so the cutover back to TW down the road should not take you very long and the risk should be reasonably low …