Package Details: pure-ftpd 1.0.49-3

Git Clone URL: (read-only)
Package Base: pure-ftpd
Description: A secure, production-quality and standard-conformant FTP server, focused on efficiency and ease of use.
Upstream URL:
Licenses: custom
Conflicts: pure-ftpd-db
Submitter: ilpianista
Maintainer: mrxx
Last Packager: mrxx
Votes: 47
Popularity: 0.367773
First Submitted: 2010-11-13 15:23
Last Updated: 2019-05-23 11:15

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

mrxx commented on 2019-01-25 12:18

simona, do: pacman -Syyu (yes, double yy). This should restore the missing symlink.

simona commented on 2019-01-25 10:42

can be... can I add manually? do you know where i can find it?

mrxx commented on 2019-01-23 10:55

simona, I cannot reproduce this. After installing pure-ftpd both on production machines and a fresh arch install, it runs without problems everywhere.

Did you install some packages with -S instead of -Sy recently? This can cause problems like that.

simona commented on 2019-01-23 10:04

/usr/bin/pure-ftpd: error while loading shared libraries: cannot open sh

mrxx commented on 2017-11-05 00:00

Upstream answered very quickly - they just fixed the bug in their development release.

I've updated the PKGBUILD, login of virtual users is working again.

mrxx commented on 2017-11-04 16:29

I can reproduce the crash when using virtual users, even with older versions of pure-ftpd.

I've filed a bug with upstream.

kitus commented on 2017-11-03 01:18

I've been working for couple of days in this problem, and i can't fix it, does anyone have the same problem... this problem happens only trying to work on "Virtual Users" , in the login process.

My Kernel:
Linux ktspc 4.13.9-1-ARCH #1 SMP PREEMPT Sun Oct 22 09:07:32 CEST 2017 x86_64 GNU/Linux

This is the journalctl result:


nov 02 20:07:57 ktspc pure-ftpd[22608]: (?@ [INFO] New connection from
nov 02 20:07:57 ktspc kernel: pure-ftpd[22608]: segfault at 0 ip 00007fe9f24fb7e8 sp 00007fff4c039c08 error 6 in[7fe9f245b000+1ae000]
nov 02 20:07:57 ktspc systemd[1]: Started Process Core Dump (PID 22610/UID 0).
nov 02 20:07:57 ktspc systemd-coredump[22611]: Resource limits disable core dumping for process 22608 (pure-ftpd).
nov 02 20:07:57 ktspc systemd-coredump[22611]: Process 22608 (pure-ftpd) of user 0 dumped core.


nov 02 10:50:00 ktspc systemd[1]: Started Process Core Dump (PID 17394/UID 0).
-- Subject: Unit systemd-coredump@7-17394-0.service has finished start-up
-- Defined-By: systemd
-- Support:
-- Unit systemd-coredump@7-17394-0.service has finished starting up.
-- The start-up result is RESULT.
nov 02 10:50:00 ktspc systemd-coredump[17395]: Resource limits disable core dumping for process 17392 (pure-ftpd).
nov 02 10:50:00 ktspc systemd-coredump[17395]: Process 17392 (pure-ftpd) of user 0 dumped core.
-- Subject: Process 17392 (pure-ftpd) dumped core
-- Defined-By: systemd
-- Support:
-- Documentation: man:core(5)
-- Process 17392 (pure-ftpd) crashed and dumped core.
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.

Any idea ?

Tnks for ur comments xD

mrxx commented on 2015-11-23 16:38

spapanik21, thanks for your suggestion. I've changed the location for the pidfile.
The libsodium problem should disappear when you update/reinstall the pure-ftpd package.

kleph's info about broken clients is now mentioned at install time.

spapanik21 commented on 2015-11-20 16:46

I noticed that the default value for the PIDFile is /run/pure-ftpd/, both in pure-ftpd.service and pure-ftpd.conf. The problem with that is that /run/pure-ftpd does not survive the restart and the service cannot restart.

The solution I am using is to change the location in both this places, but this does not survive the updates.

Furthermore, the last update broke it for me as I was getting the error:
"error while loading shared libraries: cannot open shared object file: No such file or directory" when I was using the pure-pw.

mrxx commented on 2015-10-08 02:55

Of course the FQDN of the host may not always be the desired one, especially if the server is in a DMZ, but exactly for cases like this a note how to re-create the certificate is displayed, as was suggested by you.

Unfortunately, there is not much documentation about the BrokenClientsCompatibility parameter, but the decision to set it to "no" by default in the latest release seems to be security related. Therefore, I think it's better to follow upstream and leave it untouched, as very few clients are affected.

In the next release I'll add a note about broken clients and how to enable the parameter in the config file.