Hot answers tagged

23

Restart logind: # systemctl restart systemd-logind Beware that restarting dbus will break their connection again.


8

Reboot was the only solution that worked for me. I killed the runaway dbus process and other things failed. This is what happened when i tried to reload httpd- Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org....


6

Use pam and geoip module This PAM module provides GeoIP checking for logins. The user can be allowed or denied based on the location of the originating IP address. This is similar to pam_access(8), but uses a GeoIP City or GeoIP Country database instead of host name / IP matching.


4

This was the solution. I don't know why other configs did not work! # allowing active/passive FTP iptables -A OUTPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT iptables ...


4

ProFTPd, like many other services on Unix, uses syslog to do logging. syslog is a process running with superuser privileges. This means that ProFTPd itself never has to create files in the log directory. Yes. It is as it should be. DON'T CHANGE THIS In general, any logged user activities should only be accessible by the superuser. This is to protect the ...


3

There is a second paramter to DefaultRoot ~, a group-expression which may be: DefaultRoot ~ !group_not_chrooted this means that members of this group won't be chrooted. or DefaultRoot ~ group1 this means that only members of these groups will be chrooted. So you can add group for user you don't want to be restricted to their directories or you can add a ...


3

Answering my own question: I was able to solve the problem by restoring the configuration of my /etc/proftpd.conf to AuthOrder mod_auth_pam.c* mod_auth_unix.c SELinux was configured by setting the following flags: setsebool ftpd_full_access 1 setsebool ftp_home_dir 1 Apparently the problem was related with mod_auth_unix.c which is forbidden by SELinux ...


3

May be you have error in your proftpd config file. You have to perform configuration check. The easiest way to do informative syntax check as is stated here is to run: proftpd -td10 or you can run (less noise): proftpd -td5 For sample config in your question, the result is: 2015-06-04 12:05:43,290 debian proftpd[22458]: using PCRE 8.35 2014-04-04 2015-...


3

In /etc/modules-load.d, add a file {filename}.conf. That file should have the following contents: nf_conntrack_ftp Do the following for more info: man modules-load.d Here's the doc for RHEL7: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-Persistent_Module_Loading.html


2

Try an absolute path on invoke-rc.d /usr/sbin/invoke-rc.d


2

You can use Port directive: Port <port number> A note that if you set port to N, then you must let port N-1 available too. RFC959 defined that source port for active data transfer must be N-1. You can use Port directive both in server context or virtual server context. Setting Port 0 disable server.


2

According to http://www.proftpd.org/docs/directives/linked/config_ref_DisplayChdir.html the DisplayFirstChdir directive has been obsoleted by DisplayChdir with the supplementary true parameter. So instead of: DisplayFirstChdir .message You now need: DisplayChdir .message true If you want the message displayed every time someone enters that directory, ...


2

Restarting only systemd-logind service is not enough, it just postpones the main problem. Seems like this is caused by too many files pilled up under '/run/systemd/system/', created by the service and not properly cleaned up, especially on hosts with a lot of logins. Eventually after some time you would start seeing some weird behavior like hostnamectl ...


2

FTP is a horrible protocol. It uses two ports -- one for commands, one for data. This makes it notoriously difficult to NAT, since a router would need to parse the command channel and figure out that a second connection is expected for this FTP conversation. Doing so is ugly, but also the only way to make NAT work with FTP. FTPS encrypts the command channel,...


2

Castaglia's answer is easier to use with ProFTPd, and works on any system. As a more general solution for Debian packages (including Ubuntu), you can find the configure options in the debian/rules file (that link takes you directly to the version used in 14.04): CONF_ARGS := --prefix=/usr \ --with-includes=$(shell pg_config --includedir):$(shell ...


2

I would suggest using ProFTPD's mod_geoip module, to at least restrict connections to the geographic content/country (and city, if you can). This is similar to @Ipor's answer, using the same geoip libraries/databases, except that it doesn't require PAM configurations, and is more flexible.


2

You could do this to some extend with CIDR[1] IP ranges since these can be mapped to countries[2]. You can then use an app like iptables[3] to control any incoming traffic on any port (independent of the protocol). This tutorial describes it in some more detail. In combination with CIDR the command would look something like this: iptables -A INPUT -s 64....


2

Your firewall (router) has a connection tracking helper for FTP. When it sees an FTP control connection (which it recognizes by TCP destination port == 21), it watches the commands. When it sees your client send the PORT command, it rewrites it (to your external IP address, and maybe a different port) and keeps track of the expected connection from the FTP ...


2

Quote from ProFTPD: Configuring Limits What if a site wished to allow only anonymous access? This would be configured using the LOGIN command group, as above: <Limit LOGIN> DenyAll </Limit> <Anonymous ~ftp> <Limit LOGIN> AllowAll </Limit> ... </Anonymous> The <Limit> section outside of the <...


1

Another cross-platform way to find the compile-time options for your ProFTPD installation is to use ProFTPD -V command-line option: $ ./proftpd -V Each proftpd executable contains its own compile-time options recorded, for just such situations.


1

It's difficult to answer this question because of lack of information provided (proftpd.conf, /etc/hosts, output of ifconfig and hostname). I guess it's a problem related to your changed hostname. If so, try to modify your /etc/hosts from: x.y.z.t Debian where x.y.z.t is your actual IP address, to: x.y.z.t jon-virtual-machine I've supposed your ...


1

I believe the FTP server is forbidden to access /etc/passwd or /etc/shadow. This is not true. From the AVC message, you see tcontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 which is some part of ftpd_t, not shadow or passwd (these files have different context, as you can see from ls -Z /etc/passwd). It is not complete solution, but moving forward. You ...


1

It turned out to be a small config mistake by myself. After 8 hours of brain-pain and fulle rebuilding the config file the fault turned out to be in the TransferLimit line where also the group was specified. (which is not needed because we use class definitian). TransferRate APPE,RETR,STOR,STOU 1000 group speedlimit should have been: TransferRate APPE,...


1

Well, I have got it to work in 99% First I have created groups: MF, MF1 and MF2. Then I have added all users including uberusers to the MF group. Next user1 through user3 where added to the MF1 group then user4 and user5 to the MF2 group. I have set permissions for Main_Folder_1 and Main_Folder_2 to be sure belongs to the MF group. Next step it was ...


1

I was faced with the same issue today and i found out that it was initially caused by a service eating up all available memory. I found the related log lines, which made clear that it is caused by memory allocation in the /var/log/messages log. systemd: Starting Session 750154 of user root. systemd: Failed to fork: Cannot allocate memory systemd: Assertion '...


1

The behaviour you are observing happens because even though the client has written data to the socket for the FTP data connection and the client's kernel has replied that this happened successfully (by returning successfully from the write() or send() system call), the data is still in all sort of buffers and not already committed to the destination file. It'...


1

In my case the EPERM error was caused by Large Files support enabled in build configuration. It caused _FILE_OFFSET_BITS to be defined as 64 and therefore getrlimit() call became actually a getrlimit64() call, which failed (see below). Disabling Large File support fixed the issue. I'm working on an embedded ARM application, so hopefully disabling Large File ...


1

Exactly the same thing happened to me after upgrading from Precise Pangolin to Trusty Tahr. I investigated and it looks like /etc/vsftpd.conf, the FTP configuration file, was one of the configuration files amended during the upgrade. Specifically, this line: write_enable=YES which I had previously uncommented was now commented again. I uncommented it, ...


1

Here's several problem I can already identify: #AuthOrder does not mention mod_sql.c so it will never use mysql to identify your users. AuthOrder mod_sql.c mod_auth_pam.c mod_auth_unix.c #this code shouldn't be commented in your config file and should look like this or you will never enable sql_mod <IfModule mod_dso.c> LoadModule mod_sql.c ...


Only top voted, non community-wiki answers of a minimum length are eligible