| 12:01 am on Nov 8, 2013 (gmt 0)|
|If there is a file created with PHP and chmod'ed to 0777 and I try to do step 2 on it, the ftp_chmod() fails. I'm guessing it is because it's not being run as the proper owner. |
Yes, I would agree. AFAIK you need to either be the owner of that file, or the root, in order to change the permissions of that file. You can perhaps first check the perms or is_writable() before attempting to change the perms.
When ftp_chmod() fails is there any E_WARNING or E_NOTICE triggered?
|But if I try to do the same operation with a normal FTP client, it works. |
Are you sure it is actually sending the chmod command? To be honest, I too would have expected this to have reported a similar error ...unless it is first checking the perms and only sending the command if they are different?! What is reported in the FTP console/log? Which FTP client are you using?
Maybe it has something to do with "groups"?! (That's a complete guess btw, I don't know enough about groups to comment further unfortunately.)
| 3:37 am on Nov 8, 2013 (gmt 0)|
whatever the problem is - there should be clues in the server error log file.
| 2:04 pm on Nov 8, 2013 (gmt 0)|
|Am I able to set what owner/group php ftp commands are run as? |
What ftpd are you using ?
The "stock"(*) one on most unix systems will be able to only allow access to users defined on the system that have a password and a shell listed in /etc/shells (if any).
It typically also has support for "anonymous" ftp, but that's a beast to understand on it's own and the server typically has a lot of strange things it does to allow e.g. uploads to work that can't be downloaded again. It's not just file permissions in that case.
Anyway aside of the stock one, most ftpd's do have some configuration that can be done to them.
IF you do change that, please make sure you know what effect it wil have - you might do much more than what you think you're doing (i.e. bad things can happen).
Also note that unix differs in how it reacts on suid and sgid bit on directories, not all act the same.
Your httpd typically will be running as user "www" or "nobody" -> check your apache config file.
(*): on linux there's no true stock ftpd, the distros all seem to use one or the other that were originally replacements made for one reason or another.
| 4:15 pm on Nov 8, 2013 (gmt 0)|
Thanks for the replies...
I am using filezilla. And I checked the message log and it claims it successfully sent the commands whether it actually needs to change the perms or not. So everything works here as it always has.
When I do ftp_chmod() it triggers an E_WARNING Operation not permitted.
The server is ProFTPD. And we do not allow anonymous logins. It seems like all php ftp_ functions work normally except for ftp_chmod(), but I'm going to check further into this.
I'm not really a unix or ftp expert, so I haven't tweaked any settings. After looking at the FTP logs:
- Real users only (no anonymous)
- User is always the same (it's the ftp login username)
- User ID is always * (virtual user)
- Auth method is either 0 or 1
So the auth method is the only thing different between requests. Could this be it? I still think I should get the same results when using a real FTP client vs doing ftp_ commands.
The user/group is defined by the FTP server and not the client connecting correct?
| 6:56 pm on Nov 8, 2013 (gmt 0)|
|...they are both FTP commands using the exact same login credentials. |
I know you mentioned this in your first post, but just to confirm... you are connecting using the same FTP account?
| 7:21 pm on Nov 8, 2013 (gmt 0)|
Also, in FileZilla, when changing the perms, did you actually type the numeric value, or click on the check boxes? (The check boxes have a 3rd state, "keep original value", which has thrown me a couple of times.)
| 8:23 pm on Nov 8, 2013 (gmt 0)|
Yeah, same account. And I did the checkboxes, and made sure I didn't do the keep original value thing. Every part of Filezilla works as expected. It's the php ftp_chmod() that is weird.
| 9:43 pm on Nov 8, 2013 (gmt 0)|
|...It's the php ftp_chmod() that is weird. |
Or is it? Wouldn't you expect this to fail if the owner of the file is different?
I'm puzzled why FileZilla (FTP) is successful for you. I tried this on a Linux server (file created by PHP) and FileZilla failed for me (which was expected).
|550 CHMOD 666 temp-file-created-by-php.txt: Operation not permitted |
(This is a common problem that many people face... trying to manipulate files via FTP that have been created by PHP, and not having enough permissions. Which is why people end up resorting to PHP file managers to get round the permissions issue.)
| 10:05 pm on Nov 8, 2013 (gmt 0)|
Hmm .. virtual users in proftpd ... Aside of the reason to go there if all you use is one account ...
It's going to complicate things on the server side, so I suggest you read up on the howto's:
Now just what is the code you use on th ephp function ?
Esp. how is that OCTAL parameter handed to the function ?
| 10:41 pm on Nov 8, 2013 (gmt 0)|
yeah I suppose it is weird that Filezilla works.... but I had been doing it that way for years, so that's why it's weird to me.
penders, when you did you're test, was the php created file set to 777 first?
This is the code that creates the file in the first place:
$filename = '/filename_that_does_not_exist.sql' ;
file_put_contents($filename, 'file contents') ;
chmod($filename, 0777) ;