Have you checked in/for /var/log/proftpd/proftpd.log

/etc/pure-ftpd.conf ?

I haven't run ftp for quite a while. Largely just been on NetWare (and still is at one client)

I have the ftp-server enabled on one of my servers, but do not really use it. I just discovered, that it does not work at the moment. I can only open an anonymous connection, which is unable to write. But I know, that it did work last year. Tired of chasing those problems I will probably remove it and forget it.

Is SMB via CIFS no solution? It's quite easy to configure and stable. I am using CIFS connections to OES servers for at least 10 years without major problems.

One thing, which is already configured and working is SFTP. If you need Edir-user-access via SFTP you just need to reconfigure OES LUM via yast or with namconfig to add sshd to the list of lum-enabled services.

Ken Etter You haven't provided a lot of details but I encountered a similar issue when trying to save scanned documents from a Toshiba copier to an NSS volume. I opened a case with Micro Focus and another one with Toshiba. Micro Focus identified the issue.

Here is the explanation I gave to Toshiba. Even if it doesn't help you it may help others.

Yes, I resolved my issue by enabling SMB/CIFS protocol on my server.

I will explain what went wrong and why Toshiba should update the software on the copier or at least up the documentation to explain the copier's limitations.

• Novell NetWare introduced a very robust file system known as Novell Storage Services (NSS). That was one of its main features that attracted customers.
• Early versions of NetWare only supported the IPX/SPX protocols. Later versions (5, 6, 6.5) supported TCP/IP.
• The NetWare Core Protocol (NCP) is used to access native NetWare files and NSS files.
• Despite its popularity and robustness NetWare had its limitations as a 32 bit proprietary OS.
• Novell addressed this issue by creating a new OS, based on Linux, called Open Enterprise Server (OES). It provided customers most of the same services that NetWare provided and in particular NSS.

These settings worked when saving files to the NetWare server but there is more to accessing files than just using the TCP/IP protocol. These two short descriptions from the NSS documentation explain why the above settings no longer work.

• Understanding Volume Properties. Scroll down to the Lookup Namespace section.
• How NCP Server Works.

The photocopier uses the standard TCP/IP communications protocol and the NCP protocol to access NetWare files but the UNIX/NSF namespace is specified which, for many years now, is no longer a supported combination. Everything would work as expected if the LONG namespace were specified instead. Customers have no control over this and the result is that what worked when files resided on a NetWare server no longer work when they have been migrated to OES. Of course this is completely undocumented and customers only encounter this issue after having completed a migration.

There is only one workaround: specify the SMB protocol but, by default, OES does not support NSS file access using SMB. It is a feature that must be enabled on the server but there are good reasons why some customers do not want it enabled.

So there you have it: I have spent many hours investigating this issue and delving into matters well beyond the abilities of most of your customers. It would truly be in Toshiba's best interest to update your software and documentation so that customers are aware of the issues they face.

---

Just for info,

AFAIK my pure-ftpd service is default configured on my OES servers, and i see logs in /var/log/messages

Problem is resolved!  The company that services the plotter upgraded the firmware to the latest and we tried again.  Still could not connect.  We were configuring this through the plotter's web interface.  The service tech recommended connecting directly into the plotter controller and using the built-in utilities rather than the web interface.  It worked.  He remembered running into this before - the web interface has a bug.