When I upload an addon or logo to UniAdmin v0.7.6 (or 0.7.5) the file gets CHMOD 600, but it works fine with 0.7.0. The folders addon_temp, addon_zips, cache and logos all have CHMOD of 777. I wonder what could be the problem ?

As long as the php scripts can read the files, and if you can download them, then it's ok

I fotgot to say that i can't download them, if I try to download a file I et the error 403 (Forbidden), the CHMOD should be at least 644. And I still wonder why it ist set to 600. A friend of mine was trying it to and it works (he gets 644), I checked both of our php-settings and it looks like we have the same.

my phpinfo - http://roster.ritterhp.net/phpinfo.php

my friends phpinfo - http://www.deadorglory.de/phpinfo.php

Is this a clean install or an upgrade?

both are clean droped uniadmin and db

Very weird
UA should be setting the zip files to 777 when they are uploaded

After uploading an addon I get this one but I think it's due the wrong chmod:

include/addon_lib.php
Warning line 100: unlink(/pages/24/ea/d0005025/home/htdocs/ritter/uniadmin2/addon_zips/rpgo-CharacterProfiler_latest.zip) [function.unlink]: No such file or directory
Warning line 109: unlink(/tmp/phpgRXl5C) [function.unlink]: No such file or directory

EDIT: I found something that helped me and the error above somewhat vanished due to my change:

If I comment out this line, I get the right chmod:

// Try to set write access on the uploaded file
if( !is_writeable($zip_file) )

Weird indeed

can i keep and try this change or could this cause more problems ?

this is what i changed in my uniadmin files:

./include/addon_libs.php:

Code: Select all

// Try to set write access on the uploaded file
         $try_chmod = @chmod($zip_file,0777);
         if( !$try_chmod )
         {
            $uniadmin->error(sprintf($user->lang['error_chmod'],$zip_file));
            return;
         }


./modules/logo.php line 257-265

Code: Select all

         $try_chmod = @chmod($logo_location,0777);
         if( !$try_chmod )
         {
            $uniadmin->error(sprintf($user->lang['error_chmod'],$logo_location));
            return;
         }


Code: Select all

if( !is_writeable($zip_file) ) 

I there to check if the file can be written to, then chmods it if it is not

Try this for me
Change that line to

Code: Select all

if( !is_writeable($zip_file) || !is_readable($zip_file) ) 

change has no effect, the files got chmod 600 again

i have the same problem with 0.7.8 again and solved it the same way as before

Running brand new install of v0.7.9 (clean).
Initial setup had no challenges but I noticed that all files uploaded with CHMOD of 644 whether down in the WoWAce or manually. Initially didn't think much about it until I went to update and received ...

Could not write [/home/domain/public_html/mydomain/uniadmin/addon_zips/acefile.zip]
Check persmissions

Sure enough, with 644 it cannot overwrite the files. I attempted the few suggested code changes by Sagittarius above but still without resolve. I can manually delete all the files and upload new as a temp fix but any permanent suggestions would be appreciated. Possible server side setting? Bypassable with an .htaccess modification?

FYI Please note that "persmissions" was a direct copy/paste ... so theres a misspelling in the code but not sure if that comes off the server or this app.

zanix wrote:Change that line to

Code: Select all

if( !is_writeable($zip_file) || !is_readable($zip_file) ) 

That line (114) is already present in include/addon_lib.php - version 0.7.9.

All my add on's (zip files) have permissions marks like "-rw-r--r--".
The official meaning is owner can read and write.
Group can read only,
Others can read only (and this should include my web server).
Correct me if I'm wrong, but the my web server (and thus PHP) should run with rights like 'nobody'.
Or it seems that 'my' is_writeable($zip_file) and is_readable($zip_file) tells me 'true' even when I reset all flags ???????
UniAdmin just deletes them like. Not his fault - of course, my webserver runs like what ? "God Mode" ?

Anyway, my findings are the opposite of Tcheekin - lol.

I'll have a jump to the FAQ of my hoster.... I don't get it (yet).

BTW: is_writeable() is an alias to is_writable().

edit
My hoster, ovh.net said this :

Php fonctionne en suexec, c'est-à-dire qu'il est exécuté avec les droits de votre compte ftp. Vous avez via php exactement les mêmes droits que via ftp.

PHP uses suexec, this means that it runs with the same rights as your FTP account. So, when using PHP you have to same rights as your acces FTP.

Nice, but I'm not sure that I'm happy now...

I changed my manually uploaded file from 644 to 666 and it worked. I'm wondering if it was an "ownership" issue with the file (I can't tell with the version of ftp that I use)