Description of problem: When trying to create a directory using an authenticated FTP session, the error below is shown: ncftp ...ents/fivetel/Picselect > mkdir jbtest2 MKD jbtest2 failed; [jbtest2: Operation not permitted] Could not mkdir jbtest2: server said: jbtest2: Operation not permitted Version-Release number of selected component (if applicable): proftpd-1.3.3g-10.el6.x86_64 The user's home directory is on an NFS share, on EMC Isilon storage. How reproducible: Every time. Steps to Reproduce: 1.Connect to FTP server and authenticate 2.Try to create a directory, e.g. "mkdir test" Actual results: FTP server responds with "Operation not permitted" Expected results: Directory is created. Additional info: Directory in which the new directory is being created in has the permissions "drwxrwsrwx". If I revert proftpd to "proftpd-1.3.3g-7.el6.x86_64" the problem goes away.
I see there's a SGID bit on the parent directory there; is the authenticated user a member of the group to which that directory belongs? The update to proftpd-1.3.3g-8.el6.x86_64 related to propagation of SGID bits (#1297264) so may be related.
OK, interesting, the FTP user is *not* a member of the group of the directory. In fact (this system is inherited!) the user's primary GID is not even defined in /etc/group
If you try a directory that doesn't have the SGID bit set, does that work? Likewise, if the GID is one that the user is a member of?
OK, I can confirm that either fixing the group of the directory, or removing the SGID bit fixes the issue. i.e. It only gives the error if the parent directory has the SGID bit set, and the user doesn't belong in the directory's group
"Operation not permitted" (rather than "Permission denied") sounds like an SELinux response or capabilities issue. Are you using SELinux on this system? Does the documentation for proftpd's mod_cap (http://www.proftpd.org/docs/modules/mod_cap.html) look relevant to your configuration? Note that EL-6's version of proftpd doesn't know about CAP_FSETID though.
SELinux is disabled on the system. We've not configured anything for mod_cap. The only thing "unusual" on the system is that system users are authenticated with sssd/OpenLDAP. FTP users are (for now) local users. (Completely off-topic, but sssd/OpenLDAP users can't login to proftpd, even though PersistentPasswd is set to "off")
I created an EL-6 VM with a couple of local users, made a directory owned by user1, group user1, permission 2777, logged in with proftpd 1.33g-10.el6 as user2 (not a member of group user1) and was able to create a subdirectory without issue, correctly inheriting the group user1. Do you get the same error if you use local directories rather than NFS shares?
Apologies for the delay - I can confirm that moving the directory to local storage also corrects the issue.
"Operation not permitted" looks like quite a common issue on non-local filesystems, e.g. https://forums.proftpd.org/smf/index.php?topic=11596.0 https://forums.proftpd.org/smf/index.php?topic=11997.0 A couple more questions: Are you using mod_vroot? Does using it make any difference? Is your NFS configuration doing root-squashing? There's a related patch attached to http://bugs.proftpd.org/show_bug.cgi?id=3963 but I don't think it's likely to help in this case, though I suppose we could try it.
Just tried proftpd-1.3.3g-10.el6.x86_64 on a CentOS 6 VM accessing an area served by NFS (v3) from a Fedora 25 server. Doing a mkdir in a directory mode 2755 with gid not a group that the user was in resulted in directory creation success with same gid as parent directory but no SGID bit set on newly-created directory. If the gid of the parent directory was of a group that the logged-in user was a member of, the directory was created successfully again but this time the SGID bit was inherited by the newly-created directory. I'm really struggling to reproduce the behaviour you're seeing.
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version. Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version. Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version, you are encouraged to change the 'version' to a later version prior this bug is closed as described in the policy above.
EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of EPEL please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.