Posted by cloudmaker on April 12, 2008 at 11:55pm
Jump to:
| Project: | Image |
| Version: | 6.x-1.x-dev |
| Component: | image_import |
| Category: | support request |
| Priority: | normal |
| Assigned: | cloudmaker |
| Status: | closed (fixed) |
| Issue tags: | database collation, directory not found, images, temp file, tmp file |
Issue Summary
While I have the following status report indicating that the images directory is missing, it does in fact exist. It is owned by the same user as all other directories and has permissions 755. I've checked the spelling of all the directories and I'm not sure what else to do.
Any help would be appreciated.
Greg.
Comments
#1
I have the same issue. The system says the directory is missing, when in fact it is not.
(I switched hosts and upgraded from Drupal 6.1 to 6.2 and Image 6.x-1.x-dev to 6.x-1.0-alpha1 before receiving the above error.)
#2
I have discovered that if you change the permissions to for the "files" directory, that it goes away.
Greg.
#3
#4
I am experiencing a similar problem.
I installed Drupal 6.2 on my test server (IIS 6, PHP 4.3.11, mySQL 3.23.49), got it all working fine with the Image Module (version 6.x-1.0-alpha1) but as soon as I uploaded the whole site to my online server (Apache 2.2.8, PHP 5.2.5, mySQL 4.1.22) I got the image directory could not be found message, despite it clearly being there and having 777 permissions. I also put 777 on the parent "files" folder but that made no difference.
Then, when I click on Administer I got the following two messages: "The directory images has been created." and "The directory images/temp has been created". So I checked the server and Drupal has created this new images folder on the server root. The weird part is that it started populating this new folder with images and their derivatives which it can only have gotten from the original images folder which it claims it can't see!
So, for an easy life I just copied all the existing image files into this new image folder and everything worked fine until I tried to import a new image. When I import it stores the image in the new images folder but the node comes up with a broken image in Drupal because it appears to be trying to load it from the original images folder! If I copy the image files from the new folder to the original images folder it works fine.
I then tried rolling back the image module to version 6.x-1.0-dev but the same thing happens...
#5
In /sites/default/file/settings.php, have you got $cookie_domain = mydomain.com set correctly?
I think that you will need to have that set.
Greg.
#6
I assume you mean /sites/default/settings.php, I set the $cookie_domain variable, deleted the images folder in the server root and it did exactly the same as before.
#7
I have the same problem. The folder that has all the photos is files/images and has 777 permissions.
I upgraded Drupal from 5.3 to 6.2 and updated the image module to 6.x-1.x-alpha1.
#8
I first got the same problem when I updated from image version alpha1 to alpha2.
Even after I removed image and extracted alpha1 again it did not stop, but still showed the damn error!
Though the directory definitly existed, I got that error.
I solved the files/images-error now. Allow read/write access to the .htaccess-file which is stored in the "files"directory.
BUT: Then it says: sites//files/images/temp is missing!!
make sure to allow execute rights for the image-directory, too.
in files-directory type:
chmod 777 imageschmod 777 .htaccess
mkdir images/temp
chmod 777 images/temp
I guess you could also change the owner of the files/directory and do a chmod 770 instead of 777 (and 760 instead of 766), but the above works no matter who's the owner of the files.
Hope this helps
Cedrix
PS: The preview-uses "tmp" instead of "temp", but this is not a big issue.
#9
Automatically closed -- issue fixed for two weeks with no activity.
#10
I am having the same issue and my permissions are all 777. Any other ideas since the permission issue did not solve this? I think this issue should be reopened.
#11
I, too, have the same problem. I do not believe this issue is resolved.
#12
A solution:
image.install file, image_requirements() function.
Change this:
$image_path = file_create_path(rtrim(variable_get('image_default_path', 'images')));To this:
$image_path = file_create_path(file_directory_path() .'/'. rtrim(variable_get('image_default_path', 'images')));#13
I've changed the image.install file as suggested, but I still have the problem.
#14
i have the same problem.. pls help... :( Image module directories Missing directory.
The image module's image directory is missing.
#15
Had the same issue with the Image module, and with the "Backup and Migrate" module also. Everything worked fine on my localhost, but got the same error message once i installed Drupal on the host. Here's what happened and how i solved it:
Both modules created the dirs and files ("Backup and Migrate" needs .htaccess file in it's dir), but both reported they couldn't access them.
I've tried to modify the rights with my FTP client, but I wasn't allowed to do this (the owner of all the created files/dirs was apache). So I deleted them all and created them myself (and set the permissions to 777). When I created sites/default/files/images the module made the 'temp' dir inside it, but again, couldn't write in it, and i couldn't change the rights, so deleted it and recreated it. After that everything was OK - all the error messages gone, and both modules work fine.
The Images module needs these dirs:
/sites/default/files/images
/sites/default/files/images/temp
Not sure if your issues are caused by the same problem, hope this helps! Got the idea to do this from this thread so thanks a lot! Someone who understands Apache and file ownership better should probably explain what goes wrong here...
#16
I'm also having this issue on my XAMPP localhost test environment in Windows on a site ugpraded from d5 to d6. I have tried unsetting all file permissions under files so that it's full access, tried moving it to sites/default/files/images, when I do this I get the error "Directory files/files/images does not exist."
Very confused on this matter... the folder is definitely there.
#17
Same problem here. May have found a work around for the issue. When I selected "reset to defaults" it placed a new path "sites/all/images". By taking the path reference (Sub directory in the directory sites/default/files) literally and adding to it, this leaves us with a very long path indeed. I created "/all/images/temp" under the default path of "sites/default/files" chmod to 777 to be on the safe side. You can reduce this after you test. I have pasted the dreaded message box below. I was really happy to see yellow instead of red.
* The directory sites/default/files/sites/all/images/temp has been created.
* The configuration options have been saved.
FYI. I tripped upon this 1 hour sink hole after updating to Drupal 6.12 on 06/23/09. I found this problem when I couldn't add a new content type. It would give me an error saying that the directory didn't exist. Would help if error messages tied back to the module throwing them. The other issue that came about during the upgrade was a 3 hour detour into database collation issues. Some tables were one collation while others were another after a module update. Huge stream of red error messages on record joins.
This guy saved my bacon once I found his work. This is a php script that once loaded on your server can be ran via ssh that will repair Drupal collation issues. Took all of 20 seconds to make all tables the same collation. Highly recommend it! Make sure to read the thread that it is in since there can be issues going between collations.
Nelson LaQuet
http://stackoverflow.com/questions/105572/a-script-to-change-all-tables-...
Hope this helps another crazed Drupal coder.
#18
The issue here is permissions and saving your files within the images folder:
In SSH navigate to the sites/default/files directory
# mv images imagesOLD
# cd ..
# chmod 777 files
In Drupal navigate to YOURSITE.com/admin/settings/image and save which recreates the folders /images and /images/temp
In SSH
# chmod 755 files
# cd files
# mv imagesOLD/* images/
choose "n" and enter to not overwrite temp folder or files within temp
# mv imagesOLD/temp images/temp
# rm -rf imagesOLD
#19
August 28 -2009 Same problem - I would really appreciate guidance.
Yesterday I
(1) installed 'image' 'views' and 'simple views'
(2) noticed the status report stated I needed to upgrade my Drupal instal so I did it (perhaps foolishly without researching it first)
Now
(-) I can't get the browse window to open when trying to insert image(s)
(-) when trying to configure 'files and sizes' in the images module there is an error report on the page stating 'The directory sites/default/files/* does not exist.'.
note: 'images/import' was showing the same error but when I changed the path to 'C:\vista_apps\Apache2.2\htdocs\drupal-6.13\images' it stopped barking. The set path in 'files and sizes' is 'directory sites/default/files' so I can't change to same (I would have tried digging into the CSS but have been warned to not touch any actual code. I've hacked my way around some really basic formatting code but in this case I figure I might end up doing alot of harm.
New items on status report:
(-)
Database updates = Out of date
Some modules have database schema updates to install. You should run the database update script immediately.
(-)
Image module directories = Missing directory.
The image module's image directory sites/default/files/* is missing.
Outstanding items on status report (uncertain whether I need to do something about):
(-) ImageMagick advanced options = ImageMagic image toolkit is not selected.
The ImageMagic image toolkit is not selected. The advanced options only apply to the ImageMagick toolkit. Select the image toolkit here.
(-) Unicode library = Standard PHP
Operations on Unicode strings are emulated on a best-effort basis. Install the PHP mbstring extension for improved Unicode support.
(-) Google Analytics module = Not configured
note: I am waiting until it's moved to a public server.
Theme: Arthemia-6.x-1.0
Core modules present:
(-) core enabled = aggregator, color, comment, database logging, forum, help, menu, path, poll, taxonomy , update status, upload
(-) core disabled = blog, blog API, book, contact, content translation, locale, open ID, PHP filter, ping, profile, search, statistics, syslog, throttle, tracker, trigger
(-) core req'd = block, filter, node, system, user
Modules added:
(-) enabled = image, image gallery, image import, imageMagick advanced options, imagex, (-) FCKeditor, IMCE, mollom but not register/configured, menu breadcrumb, pathauto, token, Token actions, tokenstarter, (-) google analytics but not configured, views, views UI
(-) disabled = image assist, image attach, Poormanscron, simpleviews,
A little background
It would be generous to describe me as a novice. Rather I am a gung-ho gal without any legitimate coding experience or practical training trying to hack my way around building a site. My only some what relative experience is working with Drupal in the CMS managing node updates once a pro has developed the site and building my web profile site with a pre-canned GoDaddy solution incl. adjusting some very simple formatting and graphics code. I am confident the VM, server, and initial Drupal 6.13 is set up correctly as this was done by an experienced developer less than 2 weeks ago.
#20
#21
Me again...
I de-selected all user permissions (anonymous & authenticated) in admin/user mgmt/permissions.
Now it works again; although I have no idea why.
#22
Permissions is stupid a core Drupal problem. I find dozens of people going crazy over it, just like me.
I've ended up chmoding 777 it all whenever that frustrating permissions comes up again.
I suppose it't not so good for security, but it's better than having errors all over your site.
However, still better would be to be able to go back to pure HTML...
o... and worst of all is of course the "content permission rebuild" option. It nearly always gets stuck somewhere between 60 and 97 %.
#23
subscribing, no idea.
What is weird for me is trying to change permissions for default/files/images/temp gives a FileOp error.
I tried installing/uninstalling, on and on.