QNX4 copy files to NFS share on NAS disk - cutting files

Guys please help

I have:

  • QNX 4.25H (CD 2015) installed on a new disk
  • TCP/IP 5.0
  • two models of NAS disks (experimenting always with only one of them connected) - Seagate NAS110 1TB and Synology DS119j (with 2TB WD Red inside, Synology “OS” formatted the disk with ext4 filesystem - I cannot modify that in no way)
    in the same Ethernet network, NFSfsys running, successfully mounted NFSfsys share “Public”.

I can see the share from QNX machine, can copy files (using Q-Commander QNX4 file manager - don’t know which copy “method” it uses) to that share but the files are incomplete (the end of the file is almost always cut) e.g. QNX filesize / NAS filesize (cut):
49 bytes / 0 bytes
53 / 0
2166 / 2048
3857 / 3584
9833 / 9728
477697 / 477696
As lot of them are text files, one can see that the copy (to NFS share) is really missing the end of the file.

Only certain file “sizes” are copied complete OK (uncut), e.g.:
216, 220, 228, 344 bytes
8864, 16324, 26600, 37936, 50244 bytes…

When I am copying the files with cp or mv commands, then the situation is even worse - file is “copied” to NAS Share with 0 (zero) filesize and: cp/mv says: “Host is down”.

What could be the problem? How to solve it?

Thank you

P.S.: When I try using SMBfsys, then after copying the first file to NAS share SMB mount-point “disappears” (SMBfsys crashes - SIGSEGV).

That’s me once more: I am trying to narrow the problem.

  1. I tried direct Ethernet cable connection between the QNX4 box and NAS Synology - no change.

  2. Tried to disable TCP/IP v6 in NAS box - no change.

  3. When I am copying (cp) single file from QNX4 box to NAS Share mount point (/NAS) with parameter - W (total verbose - debug) I can see:

//1/:# cp -W /qc.mnu_Prot /NAS/qc.mnu_Prot2
cp: LSTAT(/NAS/qc.mnu_Prot2,buf)
cp: LSTAT(/qc.mnu_Prot,buf)
cp: copy_guy(/qc.mnu_Prot,/NAS/qc.mnu_Prot2)
cp: OPEN(/qc.mnu_Prot,0,0)
cp: OPEN(/NAS/qc.mnu_Prot2,2401,100664)
cp: LSTAT(/NAS/qc.mnu_Prot2,buf)
cp: Copying /qc.mnu_Prot to /NAS/qc.mnu_Prot2
cp: write (/NAS/qc.mnu_Prot2): Host is down
cp: ERRS++ (1) write()

cp: past_data_copy errs_in =0, errs = 1
cp: exit_copy_guy (rc=0)
cp: CLOSE(fildes)
cp: CLOSE(fildes)

And result of that copying is /NAS/qc.mnu_Prot2 file with 0 (zero) Bytes file size.

Are these file copy problems one way (to the NAS drive) or both ways?

Presumably it’s not a bad Ethernet cable problem.

Have you tried pinging the NAS drive from a 2nd terminal while you do the file copy from the main terminal. Just want to see if the actual NAS drive does disappear for some reason from the QNX point of view or if it’s a SMBfsys issue.


Thank you Tim for inspiration. I’ll try copying (e.g. text) files even from NAS disk to QNX4 and look if they are complete.

Yes I tried this: on one QNX4 text console I was continuously pinging the NAS (pings are always/all the time perfect, response times 0 ms) and on the second console copying the files to NAS mountpoint using NFSfsys.

I tried also brand new Ethernet cable - direct connection between QNX PC and NAS disk. I don’t think it’s a hardware problem.

And: in the past I was successfully using older model of Synology - DS110j (also with 2TB WD HDD inside) for copying files from QNX 4.25 machine using SMBfsys and everything worked OK. What’s the difference?

  • Other PC and/or Ethernet adapter / it’s QNX “driver”?
  • New generation of NAS disk / it’s “operation system”? But the Seagate NAS110 1TB is quite old too.
  • Newer QNX 4.25H (CD 2015)? But I’ve tried even older HDD with older QNX4 installation and the results were the same.

So, copying the other way - from NAS share (NFSfsys) to QNX4 PC is OK, no cutting files.

Maybe this helps somebody to narrow the problem: when I copy (in Q-Commander File Manager) the whole QNX4 /bin folder to NAS share mountpoint /NAS (NFSfsys), only these 60 from 259 files are complete (uncut):

1 Audio 37936
2 Dev.par 8864
3 Dev.ser 16324
4 Dev16 28988
5 Dev16.par 12964
6 Dev16.pty 12256
7 Dev32.par 8864
8 Dev32.ser 16324
9 Efsys.pcmcia 50244
10 Fsys.aha2scsi 56568
11 Fsys.ata 26600
12 Fsys.eide 70796
13 Fsys.ide 26600
14 Fsys.ps2scsi 52032
15 Fsys.vpm50 26600
16 Net 32632
17 Net.arcxir 20552
18 Net.crys8900 27464
19 Net.ether503 25744
20 Net.ether8003 30296
21 Net.fd 26756
22 Net.fddidfe 36396
23 Net.ns83815 47560
24 Net.sis9 45752
25 Net.soho 33660
26 PcmciaBeep 9580
27 cat 8720
28 chgrp 14228
29 chown 14228
30 devu-touchintl 46504
31 dirname 5304
32 echo 7400
33 emu87 6432
34 fdformat 38884
35 infocmp 34320
36 io-usb 114884
37 io-usb-ehci 90948
38 ksh 103248
39 login 24060
40 login.qcrypt 25220
41 mkdir 10992
42 mount 15820
43 mv 11464
44 netinfo 215428
45 netpoll 8000
46 passwd 29880
47 ps 17320
48 sh 103248
49 shutdown 8988
50 slay 13024
51 stty 21976
52 ticksize 6144
53 tinit 16660
54 usb 53756
55 vplay 15876
56 wcc 531092
57 wd 598928
58 wpp386 802360
59 wprof 322064
60 yacc 60320

but when I copy “manually”: cp -W -R /bin /NAS/bin, then only first two files (don’t know why these are the first) are copied OK:

ksh 103248
sh 103248

and the third copied file:


ends with “Host is down”, target file is cut and the “cp” command terminates. It seems, that when “cp” comes to the first file with “incompatible” filesize, it terminates with “Host is down”.

One other suggestion.

Can you ‘log in’ to the NAS drive and check the SMB version. Make sure it’s running 1.0. Maybe the NAS drives are running an incompatible version (usually related to security) on their end since QNX 4 obviously will be running a very old version.

Here’s a related link for Win 10 and Synology (one of your test drives)
social.technet.microsoft.com/Fo … networking


Sorry to hihack this thread.
This brings up the issue of the use of SMBfsys. Those of us who still use QNX4 and backup aplplication data to Windows know the frustration - Microsoft trying to prevent use of SMB 1.0 and us trying to keep it working.

It’s about time that QNX came up with a new version of SMBfsys that uses SMB2 or 3.

I won’t be holding my breath. Event the Russians don’t appear to be interested.

You have my sympathy, but getting support for QNX 4? I’m pretty sure they are done with 6.5 and for a recent network utility bug I found in 6.6 (which assisted them because the same problem in 7.0) their response to whether there would be a fix was “They are only interested in 7.0”. That’s what I was told by a QNX representative.

Tim, I tried also Synology NAS’s “most defensive” setting of only SMB1 version allowed with Disabled Encryption. It’s the same: mount_smb share causes crash of SMBfsys (SIGSEGV).

ianc, I am trying (these problems describe mostly) NFSfsys. Is that possible, that no one of NFSfsys and SMBfsys work with two various NAS disks (the Seagate NAS110 is quite old)?

Maybe I am doing some systematic mistake…

I suppose you could download the source code for SMBfsys and compile it yourself and then trace the crash. Although that may be too time consuming.

Hmm, something else just occurred to me. The size of these NAS drives is huge (1 and 2 TB) by QNX 4 standards. Are the NAS drives formatted as just a single large partition? I wonder if the QNX 4 file system is having issues trying to copy to such a large drive (I forget the max size allowed under QNX 4. It’s been a long time since I seriously worked with it.). That might explain why you can copy from the drive with no problems.


Tim - in the past I was successfully using older model of Synology NAS - DS110j (also with 2TB WD HDD inside) for copying files from QNX 4.25 machine using SMBfsys and everything worked OK - and is working until now. But it is a production system at our customer’s plant, so I cannot experiment with it here.

But I can try to use some smaller HDD in the Synology DS119j.

Where would we get the source code for SMBfsys from?

You could ask QNX in the QNX4 Forum on Foundry27.

SMBfsys is essentially just the client side of Samba 2.2.12 (in QNX 6+ this is fsys-cifs) with a QNX manager wrapper around it. Given that Samba uses an open source license, QNX technically should be making the code available to you under that license.

For QNX 7, I built the base Samba source for client and server side and it was trivial.


So another experiment: I bought from second hand exactly the same NAS Synology DS110j (with 500GB Seagte HDD inside) that I’ve used several years ago with QNX 4.25 SMBfsys and it worked (and is working until now). Although DSM (NAS firmware) in this old NAS was upgraded in 2018 and looks “the same” as in current model DS119j, SMBfsys works!

But there are some issues with SMBfsys (maybe these issues were also with the former DS110j several years ago but I didn’t noticed them):

  1. I had to Disable “Time synchronization” in NAS, because when it was Enabled by Default (some NTP server from Internet), copied files to NAS got new time - several minutes different. After Disabling NAS’s “Time synchronization” source (QNX) and destination (NAS) files have the same date/time.
  2. NAS copies of “ALL UPPER CASE” QNX files (e.g. CC versus cc) are converted to “all lower case” destination files on NAS. That means the other file is not copied, because of the name conflict. Maybe some parameters of “cp” would solve that problem?

But NFSfsys is cutting the ends of most files just the same way as current model DS119j (with 2TB WD inside).

If you google “nas synology ds110j case sensitive filenames” you’ll see plenty of posts about this same issue from Linux/MAC users. The problem is definitely on their end. You may find some solution (ie you may need to format the NAS drive with case sensitivity turn on) by looking at some of the links.

Long term you might be best off by asking QNX for the source code for those 2 managers and then re-compiling/linking them against newer versions of Samba. As I mentioned above, it was very straighforward to get Samba to compile under QNX 7 so I expect it could be done for QNX 4.25.


I did ask on Foundry27 for the SMBfsys source code, but so far no response.
I wonder if the recompile/link would be straightforward on QNX4 with the Watcom compiler anyway?

Thank you, Tim, for your advice. I will google the problem of case sensitivity and try.
UPDATE: I didn’t find any solution that prevents Synology DS110j to be Case Insensitive while copying files from QNX to SMBfsys share on NAS. If I copy QNX file “CC” to NAS share, it ‘converts’ to “cc” on it. And then I cannot copy another QNX file “cc” (in lower case) to NAS share because of the name duplicity.

As to the compiling new SMBfsys and/or NFSfsys - I am not skilled enough to do that.

I believe I had the same problem with NFS and TCP/IP 5.10.
I switched back to TCP/IP 4.25 and the problem was not there anymore.

Maybe it’s worth to give it a try…