Arcamapper (SAMBA) loses connection

[Lutz Wagner]

Hi,

I wonder if anybody here ist using Arcamapper to connect to a Qnap-NAS (or other brand of NAS).

I have a Qnap TS-251D connected to my ArcaOS 5.0.4-system, with arcamapper.exe serving as a SAMBA-client to that NAS.
Arcamaper version of May 30, 2020.

Basically it works fine. I map the NAS to a local drive letter Z: on my AOS-machine (Z: having lots of subdirectories with hundreds of thousands of files). But in some circumstances I find the connection lost.

E.g. I cannot use PMView at all to view my image files on that Z:drive.  One single image can be opened, but when I start to browse through the files in that directory the Z: goes away. Same with PMFax.

Same happenes if I try to open the Z:-icon in the drives-folder

The only secure way to operate on Z:-objects seems to be from the commandline (dir, copy, delete).

I reported the problem some weeks ago to ArcaNoae, but up to now I got no satisfactory reply.

What I would like to know: Is there anybody with a similar configuration (AOS 5.0.x and a NAS attached by Arcamapper) who does *not* have the problems as descried above?

Thanks,
Lutz W.

[Dave Yeo]

Hi Lutz,
One problem that you are likely encountering is that your NAS uses EXT4 for a file system. The problem with EXT4 is weak EA (extended attributes, xattrs in Linux speak) support, maximum size of 4kbs (OS/2 usually supports 64 kb) and need to be turned on, forget exactly but IIRC, both in the kernel and in the EXT4 build as well as in /etc/fstab.
The OS/2  WPS desktop and many programs use EAs quite a bit, if you look at your desktop files, most files are 0 bytes as all the info is in EAs and programs like PMView also use them, in the case of PMView, those thumbprint icons are in EAs and likely bigger then 4kb.
So while your NAS will work fine for straight files, things like the desktop and various programs need EAs and may (will in some cases) fail.
For backup purposes, zipping things up is one way to preserve the EAs.
https://en.wikipedia.org/wiki/Extended_file_attributes

Edit, the programs built with libc also use them for things like file permissions and symlinks.

[Lutz Wagner]

Hi Dave,

One problem that you are likely encountering is that your NAS uses EXT4 for a file system.

Oops ... you're awfully right :-)

The problem with EXT4 is weak EA (extended attributes, xattrs in Linux speak) support, maximum size of 4kbs (OS/2 usually supports 64 kb) and need to be turned on, forget exactly but IIRC, both in the kernel and in the EXT4 build as well as in /etc/fstab.

That indeed seems very much likely to me.
Though I myself don't use the EAs it is probably inevitable to get involved into the EA-matter by some programs or the OS/2-system by itself.

So while your NAS will work fine for straight files, things like the desktop and various programs need EAs and may (will in some cases) fail.

Exactly!

For backup purposes, zipping things up is one way to preserve the EAs.

This not a solution in my case not at all. I have moved some applications (their data) from my ArcaOS-home to the NAS, i.e. these data are being worked upon permanently.

The manufacturer of my NAS (QNap) offers as an option the filesystem exFAT (will cost some money). Can you tell me if there are the same constraints regarding the xattrs as in EXT4? (I didn't find any info in the Wikis :-(( )

Thanks a lot,
Lutz W.

[Paul Smedley]

Hi Lutz,

One problem that you are likely encountering is that your NAS uses EXT4 for a file system.

Oops ... you're awfully right :-)

The problem with EXT4 is weak EA (extended attributes, xattrs in Linux speak) support, maximum size of 4kbs (OS/2 usually supports 64 kb) and need to be turned on, forget exactly but IIRC, both in the kernel and in the EXT4 build as well as in /etc/fstab.

That indeed seems very much likely to me.
Though I myself don't use the EAs it is probably inevitable to get involved into the EA-matter by some programs or the OS/2-system by itself.

So while your NAS will work fine for straight files, things like the desktop and various programs need EAs and may (will in some cases) fail.

Exactly!

For backup purposes, zipping things up is one way to preserve the EAs.

This not a solution in my case not at all. I have moved some applications (their data) from my ArcaOS-home to the NAS, i.e. these data are being worked upon permanently.

The manufacturer of my NAS (QNap) offers as an option the filesystem exFAT (will cost some money). Can you tell me if there are the same constraints regarding the xattrs as in EXT4? (I didn't find any info in the Wikis :-(( )

Thanks a lot,

It should be possible to enable EA's on the Qnap - however IIRC EXT4 has a 4k limit on the size of EA's - other filesystems allows 64k (hence I run XFS on my NAS).

In regard to the share disconnecting - we're going to need logs to help understand why that's happening. Do you have a ticket number on the AN Mantis? I'll see if I can find it.

Cheers,

Paul

[Alex Taylor]

I use a Synology NAS from ArcaOS with the latest ArcaMapper. (Actually, my current installed NDPSMB and Samba libraries are probably newer than what's in 5.0.6 as I have some components installed from the arcanoae-exp repo.)

I have no problems from my ArcaOS laptop browsing images on the NAS with PMView. I recently moved a lot of my DSLR photos onto the NAS and haven't had any issues.

One thing that may be worth mentioning - I have EA Support turned off for all my shares on the NAS, precisely because ext* doesn't support them to the extent OS/2 assumes. If the EAs are indeed a problem, you might be better off turning them off when mounting the share, because most programs are capable of recognizing when EAs are unavailable and acting accordingly. OTOH, if they think EAs are supported and they aren't (adequately), then I could see some things running into problems.


(Disclaimer: I work for Arca Noae, so you might not take my assurances as perfectly objective, although I assure you they are perfectly sincere.)

[Dariusz Piatkowski]

...One thing that may be worth mentioning - I have EA Support turned off for all my shares on the NAS, precisely because ext* doesn't support them to the extent OS/2 assumes. If the EAs are indeed a problem, you might be better off turning them off when mounting the share, because most programs are capable of recognizing when EAs are unavailable and acting accordingly. OTOH, if they think EAs are supported and they aren't (adequately), then I could see some things running into problems...

The approach Alex described is precisely what I have been doing on my NAS box, that being ZyXel NSA325v2 for at least a couple of years now.

I have EA support shut-off in my NetDrive NAS share mappings, that has never caused me a problem with programs like PMView, etc. In fact, our entirl PHOTO library has been migrated to the NAS, and all of these photos, as well as videos are easily accessible.

I will say the following though:

1) PMView can be configured so that when you attempt to OPEN a folder on the NAS, PMView will not attempt to create icons which are then stored in the EA...still, on my system even if I had this setting enabled and my NAS does NOT support EAs, this has never been a problem

2) Lutz, I have a situation very similar to what you describe as far as the disconnect issue goes. My NAS is mapped right at boot time...stays connected, then eventually that connection dies. I have been attempting to troubleshoot and debug this pretty much since I deployed the NAS here. No luck so far. This has remained constant through multiple releases of the Samba client, etc.

In fact what I ended up doing is to write a REXX script which is scheduled to run every 15 mins to check whether the NAS folders are still accessible. If they are not, the NetDrive control program (NDCTL.EXE) is gracefully shut-down and re-started. Following this the NAS stuff is visible once again.

Since implementing this approach I have NOT had a situation yet where I found my NAS unreachable when I needed to use it.

[Andreas Schnellbacher]

Dariusz, you've opened a thread here about your connection loss. Do you have tested if the issue persists with the files Alex has mentioned?

[Paul Smedley]

Hey Alex,

One thing that may be worth mentioning - I have EA Support turned off for all my shares on the NAS, precisely because ext* doesn't support them to the extent OS/2 assumes. If the EAs are indeed a problem, you might be better off turning them off when mounting the share, because most programs are capable of recognizing when EAs are unavailable and acting accordingly. OTOH, if they think EAs are supported and they aren't (adequately), then I could see some things running into problems.

Agree turning EA support off will likely fix the problem - but I'd also like to handle it more gracefully within ndpsmb if possible

Cheers,

Paul

[Paul Smedley]

Hi Dariusz,

2) Lutz, I have a situation very similar to what you describe as far as the disconnect issue goes. My NAS is mapped right at boot time...stays connected, then eventually that connection dies. I have been attempting to troubleshoot and debug this pretty much since I deployed the NAS here. No luck so far. This has remained constant through multiple releases of the Samba client, etc.

In fact what I ended up doing is to write a REXX script which is scheduled to run every 15 mins to check whether the NAS folders are still accessible. If they are not, the NetDrive control program (NDCTL.EXE) is gracefully shut-down and re-started. Following this the NAS stuff is visible once again.

Since implementing this approach I have NOT had a situation yet where I found my NAS unreachable when I needed to use it.

If you can capture debug logs (create a stub file x:\ndpsmb.dbg in the root of your boot drive) I'd like to try and fix this...

Cheers,

Paul

[Dariusz Piatkowski]

Hi Andreas,

Dariusz, you've opened a thread here about your connection loss. Do you have tested if the issue persists with the files Alex has mentioned?

Well, I do have:

1) 'samba-client.i686 - 4.11.12-0.oc00' installed here
2) NetDrive 3.1.6.876, which shows FileSystemDriver 3.028
3) Samba NetDrive plug-in
Vendor:          netlabs
Revision:        3.07.2
Date/Time:       18 Sep 2020 14:19:55

However, this is all running on an OS/2 Warp 4.52 SMP setup, so since it's not AOS I normally test what's being released on the AOS testers-list in terms of general usability, when requested to do so. I will report bugs only if the testing request seeks feedback in non-AOS installs as well.

In the case of Samba updates that has been the process, which is why I have been providing feedback through the list.

This is a bit of a fuzzy area because AN for the most part wants feedback that's specific to AOS installs, which I do not blame them for. That is the software stack they can control and when an issue is reported they can presumably replicate and troubleshoot appropriately. In fact there is a very stringent policy in place that says: do NOT report stuff if you are NOT running AOS.

Subsequently, other than troubleshooting here, or through some one-off email exchanges I have not logged official AOS bugs for this. I continue to test new releases, accept the risk, and if anyone that's not on the AOS path asks questions about this stuff I tend to provide my feedback.

So the short answer is: if the stuff Alex is testing with is core to AOS install and is NOT available as a RPM package, most likely I am NOT testing with these.

[Dariusz Piatkowski]

Hi Paul,

Hi Dariusz,

If you can capture debug logs (create a stub file x:\ndpsmb.dbg in the root of your boot drive) I'd like to try and fix this...

I appreciate the offer, but I'm pretty sure you have tried to help with this before, as on off-shoot to the AOS testers-list discussion, and we found that the ndpsmb.dbg wasn't showing anything. I thought your conclusion was that it may be one of the libraries that NetDrive is using and since there is no access to their source code not much could be done to debug further.

Having said that, I'm more than happy to try this again. Let me know what debug levels you want me to set and I'll let this thing run.

[Paul Smedley]

Hi Dariusz,

If you can capture debug logs (create a stub file x:\ndpsmb.dbg in the root of your boot drive) I'd like to try and fix this...

I appreciate the offer, but I'm pretty sure you have tried to help with this before, as on off-shoot to the AOS testers-list discussion, and we found that the ndpsmb.dbg wasn't showing anything. I thought your conclusion was that it may be one of the libraries that NetDrive is using and since there is no access to their source code not much could be done to debug further.

Having said that, I'm more than happy to try this again. Let me know what debug levels you want me to set and I'll let this thing run.

I'll be honest - I don't remember looking at this previously :/ There should be something in either of ndpsmb.log or at least in popuplog.os2 that might give some clues.

[Lutz Wagner]

Do you have a ticket number on the AN Mantis? I'll see if I can find it.

Yes. The ID is 0003117

But I haven't continued to communicate there... didn't have the impression that there was being worked on with much interest .... sorry. My position is: Why ask me repeatedly for lots of debug info, when it is very easy to reproduce the problem on their own systems?

Well, back to the issue itself:

Yes, I was having the EA-option set to "YES" in my Arcamapper-share-specification. I now set it to "NO" - but that didn't help nothing at all. PMView continues to crash the connection immediatley, as well as opening the drive-object in the drives-folder.

... [EAs] need to be turned on, forget exactly but IIRC, both in the kernel and in the EXT4 build as well as in /etc/fstab.

Does this mean, that for turning the EAs off it is neccessary to do this in the fstab-file as well?

Well, I don't have no fstab-file at all in my whole AOS-system. But I did find a file called smb.conf. I inserted the line "ea support = no" and here we go! PMView now works fine!

But still there is the problem with the WPS: Opening the Z:-drive-icon in the Drives-folder results in losing connection.

Nevertheless I still believe that the origin of all these problems is the EA-topic. 4kb (EXT4) vs. 64 kb (JFS).

Being a programmmer myself for 40 years I dare to say: That shoundn't be too hard to fix ...



Thanks so far,
Lutz Wagner

[Dave Yeo]

... [EAs] need to be turned on, forget exactly but IIRC, both in the kernel and in the EXT4 build as well as in /etc/fstab.

Does this mean, that for turning the EAs off it is neccessary to do this in the fstab-file as well?

Well, I don't have no fstab-file at all in my whole AOS-system. But I did find a file called smb.conf. I inserted the line "ea support = no" and here we go! PMView now works fine!

Sorry for not being clear, I was talking about turning on EAs on your NAS, if needed, not OS/2.
Glad you found a workaround, you should update your ticket, I think the problem is people just being busy and it is not that easy to reproduce your problem as the same NAS would be required and there could be other issues such as a network driver. The procedure is to always start by asking for logs.

[Dariusz Piatkowski]

Dave and Lutz,

... [EAs] need to be turned on, forget exactly but IIRC, both in the kernel and in the EXT4 build as well as in /etc/fstab.

Does this mean, that for turning the EAs off it is neccessary to do this in the fstab-file as well?

Well, I don't have no fstab-file at all in my whole AOS-system. But I did find a file called smb.conf. I inserted the line "ea support = no" and here we go! PMView now works fine!

Sorry for not being clear, I was talking about turning on EAs on your NAS, if needed, not OS/2.
...

But you do NOT need to disable EAs on your NAS box...what I was talking about in my above post was literally disabling the EAs support in your NetDrive/ArcaMapper connection setup.

You have the option right there to literaly say "this connection/share does NOT support EAs", which means that regardless of what the OS/2 application tries to do with EAs such functions will not be supported by the share where your media is stored.

The outcome of this approach is that only your OS/2 box does NOT see EAs on the NAS, even if that NAS supported EAs with whatever filesystem it's using.