SquirrelMail - Webmail for Nuts!

When saving, enter the following:

 _______ ##   ##   #    #    _____ ZZZZ ZZZ 
(  ___  )##   ##   #    #   |  ___| ZZ  Z   
| (   ) | ## ##    #    #   | |_    ZZ Z    
| |   | |  ###      #  #    |  _|   ZZZZ    
| |   | | ## ##     #  #    |_|     ZZ ZZ   
| |   | |##   ##     ##             ZZ  ZZ  
| (___) |##   ##     ##            ZZZZ ZZZ 
(_______)

Visit Preferences to set your user name

''Could not move/copy file. File not attached''

You didn't change the directory permissions so that the web server can write a new file to the data or attachments directory, or else you didn't specify the correct directory for $attachment_dir.

See DataAndAttachmentsDirectories for how to fix the permissions problem and see [http://squirrelmail.org/docs/admin/admin-5.html Configuring SquirrelMail] for how to set the attachment directory.

If you receive this message only for attachments larger than a certain size, it could be that php is restricting the size of uploaded files.

See AttachmentSize for more information on how to increase the limit imposed by php.

You may also get this error if you have the "file_uploads=off" set in your php.ini file. It should be set to "file_uploads=on"

* Also I just noticed that you can have this error if the web server user (the user it runs as), example "apache", has a disk quota of says 10MB, he is at his quota ... so this error occurs. Increase his quota. --aspicer@myacc.net (Advanced Cable Communications).

* I had the same issue when I copied the files over from an older Red Hat box to Red Hat Enterprise 4.  What worked for me was:  restorecon -R -v /var/lib /var/spool  That little nugget of joy came from a post by Daniel Walsh @ Redhat.  I spent hours thinking it was a regular permissions issue until I wised up and looked in /var/log/messages and saw the SELinux message.  That apparently reapplies the policy to the directory/files.

You need to add whatever your upload_tmp_dir is to the open_basedir as in 'open_basedir /wwwroot/:/tmp/' (plagiarized from move_uploaded_file docs comments). This directive is NOT affected by whether Safe Mode is turned On or Off.

If you have safe_mode=on, you can also try to add the upload_tmp_dir as an absolute path instead of a relative path. It is then not necessary to add the directory to the open_basedir (using version 1.4.1)

*If you're running PHP < 4.3.3, you cannot rename() files across different partitions, and you might get this error.

I received this error on Fedora Core 3 until I disabled selinux.  In order to solve this problem, I first verified my apache user owned $attachment_dir, gave $attachment_dir 700 permissions, checked my php.ini file to ensure I had "file_uploads=on", and verified my upload_max_filesize setting in php.ini was large enough.  The default was 2MB, large enough for my needs.  I then disabled selinux by setting SELINUX=disabled in my /etc/selinux/config file and rebooting.  (I'm sure there ways of disabling selinux w/o needing to reboot.)

*Another cause of the error can be in the $attachment_dir specification in config/config.php. In my case what should have been "$attachment_dir = $data_dir . 'attach/';" ended up as "$attachment_dir = "$data_dir . 'attach/";". That happened because the configure script as of 1.4.10a has a bug, and will produce the corrupted, nonworking version if used to save a config.php file with such a path specification. (The bug is in the "sub change_to_SM_path()" function, which wants to throw quotes around any $attachment_dir spec with an initial "$" - thus allowing $data_dir/attach to work despite its sloppy syntax, while breaking the good syntax I was using.)

Summary of change:
Add document to category:

Editing DirectoryPermissionsProblem