chmod broke mail?

Discussion in 'General' started by breakaway, Aug 3, 2007.

  1. breakaway

    breakaway New Member

    Hello,

    I recently had a user run

    Code:
    chmod -R 707
    on everything inside the /var/www/ directory. In order to acces

    Code:
    
    
    This consequently broke postifx. It shouldn't have, right? :confused: I ran the
    Code:
    postfix check
    command. This returned 2 permission errors, so I ran
    Code:
    postfix set-permissions
    This command executed successfully, but I still kept getting an error about inability to access /dev/null.

    So just to see if it fixes it, I ran chmod 777 on /dev/null. This fixed it all. I then compared the permissions of /dev/null is on another system, and on setting the permissions to what they should be (chmod 666). I set /dev/null to 666, and this broke the mail again. Had to have it on 777 or it doesn't work.

    I presume it's bad to have /dev/null set to 777. Any ideas on how I can fix this up?
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    This breaks postfix for sure as you changed the permissions of all mail directories. Every directory under /var/www has specifix permissions.

    You should never run a chmod or chown on the /var/www directory!

    To fix this, Please run the following SQL statements in the ISPConfig database:

    Code:
    update isp_isp_web SET status = 'u' WHERE status = '';
    update isp_isp_user SET status = 'u' WHERE status = '';
    then login to the ISPConfig interface, change a value on one of your websites, e.g. quota and hit save. ISPConfig will then update all your sites and correct the permissions.
     
  3. breakaway

    breakaway New Member

    But at the moment I have /dev/null set to 777. Do I just leave this or do I put it back to 666?
     
  4. falko

    falko Super Moderator ISPConfig Developer

    The permissions of my /dev/null are 666, but 777 should work as well. If you don't get any errors regarding /dev/null, don't change it.
     
  5. greenpete

    greenpete New Member

    I have been having permission problems from the start.
    When I have tried to login vie WebFTP I couldn't then via client I could but couldn't upload.
    I have since messed with chmod -R /var/www/web5/web many times and get varying results though it 'fixes' the problems I am having at the time.
    Tonight, whilst trying to get my head around the problem I notice that having 777'd the whole web directory in order to upload something I can only reset permissions in FireFTP on some directories!
    All files and directories say they are 777 but only some allow me to change them.

    I have no problems to my knowledge any where else on the system, i.e. mail.

    Should I reset permissions and if so how would I go about it, would it be the way Till explains above?
    i.e...
    update isp_isp_web SET status = 'u' WHERE status = '';
    update isp_isp_user SET status = 'u' WHERE status = '';

    Or does this only apply to the postfix problem?

    Thanks.

    Running Perfect 6.06. LTS with ISPConfig
     
    Last edited: Apr 9, 2008
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    You should reset the permissions by following the steps that I explained above.
     
  7. HardyHarvey

    HardyHarvey New Member

    Hi all. First post for me. I'm on Ubuntu 6.06 w/postfix. I have many issues but wanted to share one of the band-aid solutions i've happened upon:

    Permissions game: first of all thanks Till for the 'how to reset default permissions' hack in mysql. This will be very helpful to future ispconfig noobs.

    My biggest issue was that the ftp user created by postfix didn't have write permissions to the /var/www/web5/web folder, or if it did then it just doesn't serve the pages. I discovered this after 'sudo cp /old/folder /var/www/web5/www' brought the wrong permissions with it (root.) (Also I manually changed each ftp user's home directory to their web folder so it would be transparent to web uploaders, in /etc/passwd)

    ANYWAYS I fixed broken permissions with:
    Code:
    
    [email protected]:/var/www/web5$ chown www-data web -R
    [email protected]:/var/www/web5$ chgrp web5 web -R
    [email protected]:/var/www/web5$ chmod 755 web -R
    
    I did this for each web## subdir in /var/www, which has about ten at this point. This gives the right permissions for the web folder as listed on page 30, in the appendix of the admin manual, except that the owning user is the ftp user instead of nobody.

    Now I can upload with the ftp user (named 'mydomain', with no web##_ prefix) and things seem to work great.

    We have gone live with the server (don't ask) and so i hesitate to mess with the entire permission structure of the site, it's working for me atm..

    Email: the instructions i followed for 'the perfect setup' doesn't have a bullet beside 'pop client' so I didn't get courier installed on the server until day fifteen (one-two hours farting around per day is just wrong) Now I'm opening a whole new bag of worms, am I screwed or is it possible to get courier-pop to integrate into ISPConfig after the fact? It shows as status 'Online' but I understand that is just based on the port being open.

    TL;DR: How do I configure courier-pop if it's installed after the fact?

    Cheers
    Harvey
     
    Last edited: Apr 10, 2008
  8. falko

    falko Super Moderator ISPConfig Developer

  9. greenpete

    greenpete New Member

    I followed your instructions and all seemed to go well. But I still have some directories that have permissions of 777 that will not change using an FTP client, I get error 550.
    I have to say I can't see how a change to the ISPconfig data base would effect the permissions of directories, but then I wouldn't be here if I knew things like that! :D
    Is there anything else I can do?

    Edit: Is it likely that this has anything to do with file or directory ownership?
    I have read elsewhere in these forums that ownership of files and directories can be an issue so I downloaded relevant directories and then re-uploaded them after deleting the remote copies using client FTP and this worked!
    Sometimes I could delete the originals using the FTP client others I had to use SSH and 'rm -r /var/www/web1/web/dir_in_question'.
    Directories then had 775 permissions but I can now change them as needed.:)

    Edit2: I think (but cannot be sure) that I created this problem my self by shelling (is that a correct term?) into the server using the admin account and 'wget'ing files for other domains, thus admin owned the files not the user of that domain.
    Sounds like a stupid thing to do now, but then hind sight is a wonderful thing!
     
    Last edited: Apr 15, 2008

Share This Page