Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I'm sure I've done something wrong, but I don't know what it is. I have everything set-up as best as I can, but I get this error:
* The selected file /tmp/tmp_swAcPL could not be uploaded, because the destination /tmp/audio/breathing.mp3 is not properly configured.
* The following errors where encountered while reading the file's ID3 tags:
o Could not open file ""
* Title field is required.
Can somebody please put me back on track?
thanks
evan
Comments
Comment #1
drewish CreditAttribution: drewish commentedthat looks like some kind of permissions problem with the webserver in the temp directory. have you had any luck uploading with the upload module?
Comment #2
Evan Leeson CreditAttribution: Evan Leeson commentedYes, no problem with upload module. Video module working well also. php upload limits sky-high. I evan put a tmp/audio directory at the root of public_html to test and see if that was the problem and even chmoded to 777 and still the same result. Where exactly does this tmp/audio directory normally live?
Comment #3
Evan Leeson CreditAttribution: Evan Leeson commentedOK, I went back and checked. I'm using attachment and filemanager, not upload. However, I enabled them upload module. Then in audio content type I enabled both "attachments" that appear after enabling upload module. Then I configured upload to allow .mp3. I created a tiny mp3 so file size is irrelevant. Still get the same errors. In the drupal admin log I see three new lines each time I try to upload an audio file:
help! It looks like something is wrong with the destination directories, but I don't see those listed directories (tmp/audio) in the root of public_html. There is a tmp director at the root of the virtual server, above the public_html directory.
Comment #4
Evan Leeson CreditAttribution: Evan Leeson commentedI also disable attachment and file manager. I also reset ID tags setting to default. Still get the exact same erros in the log. Here is a more verbose error message:
Comment #5
drewish CreditAttribution: drewish commentedyeah it should be using /tmp (the server's temp directory) to store the files you've uploaded. it then tries to move them to a directory in temp named audio. if you said that the directory doesn't exist, then it looks like that's where the error is occuring. maybe you could try creating the directory manuallly and see how that works?
Comment #6
Evan Leeson CreditAttribution: Evan Leeson commentedStill throws the exact same error. Same on two sites now on the same host. The directory tmp site next tp public_html and is world writeable. I put an audio directory inside which is also world writeable. Any other ideas? .htaccess file issues? php.ini issues?
Comment #7
Evan Leeson CreditAttribution: Evan Leeson commentedsorry..in a rush...the tmp directory sits next to the public_html directory.
Comment #8
drewish CreditAttribution: drewish commentedsee also: http://drupal.org/node/65211
renaming this to make it easier to find.
Comment #9
drewish CreditAttribution: drewish commenteda few questions:
* do you get this error on preview, on submit, or on both? (i'm assuming both)
* do you see any errors listed on the admin screen that might be related?
* can you try changing drupal's temp directory to drupal/temp or something like that?
Comment #10
jeforma CreditAttribution: jeforma commentedyes, I am getting the exact same errors as you, I wonder what's wrong...
Comment #11
drewish CreditAttribution: drewish commentedhey cheif, those questions go for you as well...
Comment #12
jeforma CreditAttribution: jeforma commentedOk, here are the errors that this gave me when I tried to upload another song.
This is the error that it gives me no matter if I preview or submit:
These are the three errors I get everytime I try to upload a song in my admin logs:
and I do not have a tmp directory, well not that i see in my ftp, if I create one it will not do anything, if I change it, it will also not do anything...
Thanks for your time :)
Charles
Comment #13
Evan Leeson CreditAttribution: Evan Leeson commentedI thought I posted my fix for this. I changed the Temporary directory in Drupal/admin/settings/file system to "files" and the problem simply disappeared. I think some hosting environments don't like it if you are using a tmp directory inside public html for this, or trying to name another directory tmp. "I should point out that "don't like" is NOT a technical term and is in no way meant to explain the problem. It just seems that way to me.
I should also point out that Site5.com has clearly changed something about their environment becasue the module now works out of the box. The tmp/audio directory is created without any trouble. Somebody fixed something on my server and din't own up to it.
Comment #14
jeforma CreditAttribution: jeforma commentedYes, thank you very much, that fixed it my friend. :)
This should be pointed out in the README file drewish, it works after this, I am just getting some ID3 tag errors, but I am assuming that this is normal.
Thanks for all your time ;)
Charles
Comment #15
d.b.s CreditAttribution: d.b.s commentedI had a similar problem, and took hours to try to figure it out. Changing the temp directory to files didn't work. Changing files permision to 777 didn't work either. I kept getting the same error, unable to upload because the destination is not properly configured, where destination was actually only the name of the file, not including a full path to it. Looking at the error log, it was trying to write in root. ("The directory . is not writable").
I'm posting my solution here, in case anybody else has the same problem.
What solved it for me was to change the administer / settings / file system settings / File system path from files to /full-unix-path-to-drupal/files. Same for Temporary Directory.
Now, why I have to do this, I don't know. If anybody could help me understand it I would appreciate it.
Cheers.
Comment #16
drewish CreditAttribution: drewish commentedwith no additional feedback i'm going to assume you got this working. feel free to reopen if that's not the case.
Comment #17
(not verified) CreditAttribution: commentedComment #18
patrickmj CreditAttribution: patrickmj commentedForgive me if I'm adding this is in the wrong place--I'm new to PHP and to Drupal...
The above solution worked great for me, except it broke images already on my site because it gave a different file path. I worked around it with the following cheesy hack on audio.module, line 546 ff., hardcoding in the full path as d.b.s. did:
If my PHP skills were better I'd try to give more, but I hope this helps someone out there.
Comment #19
(not verified) CreditAttribution: commentedComment #20
WeRockYourWeb.com CreditAttribution: WeRockYourWeb.com commentedI experienced this same problem with acid free photo galleries when transferring to a new site. I ended up having to uninstall the modules image, filemanager, and acidfree, and delete their corresponding DB tables. After reinstalling I reconfigured permissions and everything works fine.
Alex
----------
Contract Web Development
Comment #21
Baker CreditAttribution: Baker commentedJust to reiterate for those like myself that skip to the bottom of these to get to the solution the quickest...
If you're receiving this error with 5.x, you want to go to Home > Administer > Site Configuration > File System and modify the Temporary File Directory field to reflect the correct location of a directory that Drupal can write to. Mine was set to /tmp which not only didn't exist, but I believe the slash in front would have messed with it even if it did exist. I changed mine to files/tmp and everything works fine.
Thanks for the great advice from all of the above contributors. I just wanted to put a cap on things for the terminally impatient like myself.
Comment #22
Pushkar Gaikwad CreditAttribution: Pushkar Gaikwad commentedGuys my problem is NOT related to audio module but I am getting EXACT same error. I am uploading images but not able to see them. I have just changed my host and it seems the problem is caused because of changing the hosts.
I tried all the combinations of Home > Administer > Site Configuration > File System in my 5.3 but it is still not working!
I don't get any error as well, it is just that the image don't gets shown! What might be the problem ?
Comment #23
jmcclare CreditAttribution: jmcclare commentedI have some more information on why this issue happens (it just happened to a site I work on).
I found that Drupal was leaving tmp_* files in the /tmp directory. This may be caused by users uploading a file and cancelling the node edit form, or errors or timeouts after the file was uploaded and saved as a tmp_* file. It seems that you get an error when you upload a file and the tmp_ file Drupal tries to create for it already exists.
I deleted all of these old tmp_ files from the /tmp directory and Drupal was once again able to upload and save the files we were having problems with.
Drupal should clean out these old files during cron runs, but in lieu of that I have setup a simple cron job to run every morning at 5:00am and delete any of them that are older than one week:
0 5 * * * find /tmp -name "tmp_*" -type f -mtime +7 -exec rm {} \;
Comment #24
cindyr CreditAttribution: cindyr commentedFor anyone who has read through all this and still gets the "because the destination is not properly configured" error, let me point out that you need correct file permissions set not only here: Home > Administer > Site Configuration > File System but also under the module settings. E.g., in my case, Node Images.
Comment #25
drewish CreditAttribution: drewish commentedcheck if your host has open basedir restrictions that might be preventing access to the directory.
Comment #26
Andrew_Mallis CreditAttribution: Andrew_Mallis commentedThe problem is most likely related to file ownership rather than persmissions. If you are running Apache as the user apache, chown your files directory to apache:apache.
Comment #27
mennonot CreditAttribution: mennonot commentedI ran across this problem with the FileField module. After trying nearly evrey solution suggested above unsuccessfully, changing the user using chown (as suggested by Andrew_Mallis) finally worked. I also chowned the directory created by the File Field module the file field settings (i.e. files/filefield).
I suspect (but cannot prove) that this error message may sometimes be misleading because it points to the tmp directory (or whatever is set in the file system settings) when the directory the file is being moved to (usually created by the module) is the one at fault.
Comment #28
Blackstorm CreditAttribution: Blackstorm commentedSorry for the reopening of this, but I've some serious trouble in using the file upload. The error is the same, but for some reason i cannot unset the read-only attribute on windows wamp folder. I've read saomething about, it seem tha tha apps mostly ignore the read-only attrib for the folder. How can I resolve this prob?
Comment #29
joehudson CreditAttribution: joehudson commentedIn D6 if the directory you want to move a file too is not in your 'files' path set in your site config you can't use the api functions: file_move, file_copy or file_save_upload because they all call file_create_path, which requires that the file destination is in the site 'files' path. So, if you want your module to use a different directory, store it using say variable_set('mymodule_files', path) and basically copy the api functions into into mymodule_file_move() ... etc. but remove the call to file_create_path and replace with a check for your modules file path (don't just allow any old path, it's asking for trouble!), and call those functions instead. Hope that helps :)
Comment #30
berenddeboer CreditAttribution: berenddeboer commentedAnother solution: I used a custom module which called file_save_data(), but the target was outside the Drupal directory which appears to be forbidden.
Comment #31
cjsolvesit CreditAttribution: cjsolvesit commentedI an using version 6.x. I had every problem on this list and I finally got it to work. My situation was images but it was a problem with the file system configuration:
1) There was a conflict with the Pathauto module. After I disabled Pathauto it worked!
2) On my install on a shared server, /tmp is actually /home/greatbas/tmp. put "/home/greatbas/tmp" in the "Temporary Directory" field on admin/settings/file-system.
3) I am using a multisite configuration. in admin/settings/file-system the "File System Path" starts at the server public_html/ directory. Enter "sites/greatbassguitars.com/files" in this field to access the "files" directory in your home directory.
I hope that this can save someone else about 4 hours!
Comment #32
JerryH CreditAttribution: JerryH commentedSame issue here, also none of the tokens are being replaced !!
Though we can't turn pathauto off.
Comment #33
PieWie CreditAttribution: PieWie commentedI have the same (but with the img files)
[code]Failed to send file sites/default/files/img/user/user25/1.jpg because the destination directory is not properly configured.[/code]
chmod for sites 755 or 765 or ... or 766 or 777 does not matter
chmod for default 755 or 765 or ... or 766 or 777 does not matter
chmod for files 777
img directory created by Drupal
I use
Drupal 6.16
Token 6.x-1.12
ImageField 6.x-3.3 or ImageField 6.x-3.2 does not matter
FileField Paths 6.x-1.4
FileField 6.x-3.3
Comment #34
jnojr CreditAttribution: jnojr commentedIt appears that Drupal writes a tmp file, and then goes to write to items in sites/default/files Double- and triple-check the ownership and permissions all the way up and down the file system. I leave my drupal home directory owned by me and a group that others can be in, and give 775 to directories and 664 to files all the way down. Then, I chown -R apache sites/default/files and apply 770 permissions for directories and 660 for files to sites/default/files and everything underneath. This prevents issues with world-writable directories... some hosting providers will find and disable them.
Same goes for your tmp directory... I use /var/www/html/tmp owned by apache with 770 permission There is probably no reason why you can't use /tmp but by giving apache it's own temporary directory, you ensure that nobody else can fill up /tmp on you
Comment #35
suffering drupal CreditAttribution: suffering drupal commentedSame stupid problem.
# The selected file /tmp/fileG4PNVz could not be uploaded, because the destination is not properly configured.
# The selected file /tmp/filekS2KcW could not be uploaded, because the destination is not properly configured.
# The selected file /tmp/fileKoYLWF could not be uploaded, because the destination is not properly configured.
# The selected file /tmp/file4hOgFd could not be uploaded, because the destination is not properly configured.
# The selected file /tmp/fileIhoPNL could not be uploaded, because the destination is not properly configured.
# The selected file /tmp/fileg0Sixk could not be uploaded, because the destination is not properly configured.
What I don't understand is why it doesn't say WHAT that destination is, so you can GO there and, in fact, CONFIGURE it properly.
(just like when you get "....... destination file sites/default/files/js/gmap_markers.js is not properly configured.")
It's like someone telling you that for getting to your destination you have to "take the RIGHT way"..... >-((
Comment #36
hansrossel CreditAttribution: hansrossel commentedSome things you can try:
- Try /tmp and tmp for temporary directory
- Resave the file system settings page
- Make sure permissions for all files are 777: on server: chmod 777 -R files, or you can do this by right clicking on the folder in an ftp program like Filezilla
- Make sure your apache user owns all the files: chown myuser:myuser -R files. This last one is very important and often the cause and should be fixed by the hosting company if you don't have command line access yourself. If your apache user does not owns the files directory, Drupal will not be allowed to create new directories, so giving errors. myuser is not your Drupal username but the login to your hosting control panel (or just apache username).
- Check the same for the tmp directory
And I don't think this has anything to do with audio module, its just permissions and ownerships of files on the server.
Comment #37
jason.fisher CreditAttribution: jason.fisher commentedThis probably does not belong to the audio module any more .. but it may not make sense to move as I don't see this being fixed in 6.x and 7.x seems to use a different strategy.
The problem that I see is that %destination is never actually displayed, but the sentence kind of makes sense still.
includes/file.inc:
The problem is that file_create_path() can return a null or empty value in certain conditions. $dest is being overwritten immediately by that. $dest is then no longer available to display as %directory -- thus you do not get to see what module or directory is actually causing the issue.
I had to change this to save the $dest variable before sending it through file_create_path, and then use that for %directory instead, in order to discover that menu_icons was causing a problem. This seems to be related to menu_icons trying to do something without using a path prefix? It was just trying to use "menu_icons/menu_icons.css" instead of "sites/all/files/menu_icons/" I believe.
Jason
Comment #38
ezra CreditAttribution: ezra commentedI had a similar problem on my dev server. I had copied everything from live except the files directory (site/default/files). That was somewhat intentional -- we do this often when making dev servers for sites with large file repositories in the files directory. I even tried making a new files directory and setting it as writable, but that didn't help.
What ended up working in the end was copying the files directory in it's entirety from the live server. Why, I'm not sure, but perhaps this will help someone else.
Comment #39
dziemecki CreditAttribution: dziemecki commentedThis thread got me looking in the right direction but what ended up being the problem for me was that I had to point my tmp directory under File System configuration to a directory that actually existed.
Comment #40
shiva_123 CreditAttribution: shiva_123 commentedIn Drupal 7 , while uploading a file using "managed_file" filed I am getting message as "destination is not having permission
Comment #41
zirafa CreditAttribution: zirafa commentedYou can't use a 6.x module with 7.x core.
Comment #42
JamFar CreditAttribution: JamFar commentedHope you will port your module to Drupal 7.
Comment #43
captaingeek CreditAttribution: captaingeek commentedWe're using this module extensively. I'd like to offer a bounty on migrating this module to D7. Goals are to be able to upgrade / migrate this D6 site http://degimedia.com/index.php?q=audio/by to D7. Any interest?
Comment #44
esbon CreditAttribution: esbon commentedSubscribing
Comment #45
kjv1611 CreditAttribution: kjv1611 commentedSubscribing
Comment #46
yugongtian CreditAttribution: yugongtian commented+1
Comment #47
cmcintosh CreditAttribution: cmcintosh commentedIm interested in rolling this as something that utilizes the Media Module. I think that making it more integrated. To start off im really just going to use a field formatter, Ill post that and we can see where to go from there if there is interest.
Comment #48
gadams CreditAttribution: gadams commentedChanged Title to be more specific when looking at issues in personal queue.
Subscribing because this is an awesome module.
Comment #49
kebap CreditAttribution: kebap commentedI ran into this problem when I was trying to clear the cache.
Using menu_icons module led to this problem. Solution in http://drupal.org/node/62749#comment-3464004
Printed out all the paths of the processed files by editing 'includes/file.inc'
Then changed the menu_icons.module file:
Then, create the folder 'sites/default/files/menu_icons' and assign the apache user and group to it and give some proper permission settings. I've added 775 - less might be working, too.
Comment #50
acrollet CreditAttribution: acrollet commentedChanging this issue back to its intended purpose. Anyone interested in this issue for the menu icon project, please see: http://drupal.org/node/1200004