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
or
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).
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):
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:
sinit
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”.
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.
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)?
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.
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):
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.
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.