#1
|
|||
|
|||
[Aborted]: No permissions to write to harddisk ERROR
I have this error, how can i fix it? Thanks for viewing. Last edited by Jiaz; 23.03.2010 at 10:59. |
#2
|
|||
|
|||
This is not likely a jdownloader problem. Check for problems with free disk space, harddrive errors, standby/hibernation settings etc.
|
#3
|
|||
|
|||
Download from rapidshare.com is good, but i have this error when download from mediafire.com. My harddisk, free disk space is good, =.=
|
#4
|
|||
|
|||
Disable the download and then re-enable. Failing that, Reset the download. Failing that, Remove and re-add the download. Good Luck.
|
#5
|
|||
|
|||
I am also getting the same error message sometimes. I have a rapidshare pro account and plenty of space on the hard drive.
Here is my error log: http://jdownloader.org/pastebin/5513...b0ffeac130dca8 |
#6
|
|||
|
|||
Please try to reduce chunks per file number to 2, reset download and try again.
Mediafire can cause many various errors, because MF fights with JD. |
#7
|
||||
|
||||
connection reset = firewall or disconnect or too many chunks(cant say because of short log)
__________________
JD-Dev & Server-Admin |
#8
|
|||
|
|||
I think this occurs when you are downloading a lot of files and some of them are large archives which takes a longer time to extract the RAR files with the JD-UNRAR plugin, at the same time you are still downloading more files while it's trying to extract large archives. Because this occurs with me when I do this. FYI, I got JDownloader set to download the files unto an external HD connected with USB 2.0.
Last edited by Jay-Jay; 11.07.2009 at 16:57. |
#9
|
|||
|
|||
if you are sure that you have enough free space then it is a virus inside archive that you are downloading and your antivirus is preventig it to be writen to HDD.
i had same problem,wasnt sure what was goin on then i checked antivirus logs and it was all clear. |
#10
|
|||
|
|||
No viruses here.
|
#11
|
|||
|
|||
I've had this error many times with outdated plugins.
|
#12
|
|||
|
|||
I can tell you where it comes from:
If the file has been downloaded and is complete, sometimes the program doesn't recognize it correctly, tries to download more, but there is nothing more to download... I had that more or less every day now and I solved the situation by renaming the RAR file from ...RAR.PART into ...RAR And guess what... it unpacks the archive in a totally normal way I guess that this is just a program flaw, nothing else Judith |
#13
|
|||
|
|||
Could you please tell the devs which host(s) is/are affected?
Thanks |
#14
|
|||
|
|||
Quote:
no matter what hosts or how many i download from at once, this error occurs every 2nd day or so out of the sudden. all running downloads are failing then and set to the described error-message + they are disabled. i have always using 1 chunk only and never used the unrar plugin, so i can trace it to the level, that those, like some people assumed in this thread, are not the cause of the problem. |
#15
|
|||
|
|||
All the hosts are affected.
So it should be fixed? The files are tried to be written at the same time if there are too many chunks? Need to solve the access conflict with some locking technique. |
#16
|
||||
|
||||
it happents to me when I used Panda antivir.
I have change to NOD32 and no problem now. |
#17
|
|||
|
|||
pls, this hasent anything to do with antivirus software.
i use avira and it happens nevertheless. a friend of mine reported the error too and guess whats he using? yea, panda |
#18
|
|||
|
|||
I had this error from time to time with NOD32
|
#19
|
|||
|
|||
i think you're right
Quote:
had the same prob downloading an .mpg from DepositFiles (Premium Acc.) checked the 'part' file-size against the expected total file-size and was indeed a match, even tho package showed only 90% complete. renamed part-file (removed '.part') and played the .mpg. all the way the the end with no errors. the file was indeed complete. have never had this problem when downloading with max connections set at 1. this time had up to 5 simultaneous connections could it be that jdownloader is missing some chunks in it's percentage count when using multiple connections? if so, try the solution quoted above before resorting to a reset. you may find you already have a complete file.:thumbup: |
#20
|
|||
|
|||
i dont think so at all
sorry guys, but this error happens here frequently and it happens no matter i have 1 download running which is completed 5% or 3 downloads running where 1 download is at 20, the other at 30 and the third at 40 percentage.
if this were true, then tell me, why jdownloader downloads those file correctly the next time after you have reset the downloads. after what you say, it should calculate the size wrong again, but no: out of the sudden, the new downloads work flawlessly |
#21
|
|||
|
|||
This happens to me when I try to use link grabber to grab .dlc links.
If you download the .dlc file manually. Goto the folder where the file is downloaded to and then add it to jdownloader by dragging the .dlc file onto the download window of jdownloader it works great. |
#22
|
|||
|
|||
I'm having problems with this no permissions error also. Can't see any consistency.
|
#23
|
|||
|
|||
Please, read this thread from the beginning.
|
#24
|
|||
|
|||
It seems to be a server problem. It happens when your download is somehow disrupted, and you have been disconnected, but on the file server side (MU, RS, etc), they still detect your IP status as downloading. As a result they deny you to reconnect or resume download. Since there is no such error message as:
"Your download has fuxxored. Please resume or begin the next download later, or when the server side has acknowledged that your download has been aborted, and thus freeing up your IP for the next download." Unfortunately JDownloader can only blindly attempt to reconnect, so all your downloads begin to show "no permissions to write to hard disk", such as what you see here... This is getting to be a mega issue with RS, which doesn't allow resuming. So if you see a page full of 200 meg segmented files, and you know your server will take a big dump on you, then I'd advise that you just walk away. |
#25
|
|||
|
|||
@updown: RS does allow resuming.
The problem seems to be a deadlock caused by JD when trying to write to disk. It has nothing to do with RS, MU, FF, etc. It's a problem with JD itself. This error occurs frequently to me when using a faulty internet connection and it doesn't matter if I'm downloading from RS, MU, whatever. Resetting the file works sometimes so half of the time I have to add the link again. Changing the num. of chunks to 2 didn't help either. |
#26
|
||||
|
||||
Quote:
Connection Reset, Connection Timeout, Read Timeout...all those errors come from instable Internet, firewall and so on , but NOT from JD (you can google the error if you want) only because part files has the right size, does NOT mean they are completed, just imagine 2 chunks, chunk 1 is dead, chunk2 is complete so the file is correct filesize, but 0-50% empty, 50-100% correct we need logfiles and information about os/java/firewall to try to help
__________________
JD-Dev & Server-Admin |
#27
|
||||
|
||||
The message is misleading, people will always make a new report about this.
Is it difficult to write a new message about bad connection problem? |
#28
|
|||
|
|||
Does anyone still have this problem?
I do, and I'm on the latest JD.. On a 3mbps connection, I see this problem at least once a day... usually it shows the *.part on disk to be bigger (Sometimes full sized, but still with .part extension) than the %/size shown within JD. Could it be because JD preallocates the space and then fails to readjust it when an unexpected interruption happens? For example when there's connection time out or server disconnection? Thank you. |
#29
|
|||
|
|||
Quote:
Sometimes JD finishes downloading the file but I can still see that the ".part" suffix is still appended to the file. What I've done in this case is to simply rename and remove the ".part" extension and see if it works. It's always worked for me. |
#30
|
|||
|
|||
Yes, exactly. I think the Bad CRC is caused by wrong marker (where JD think the file should be resumed is not accurate with what's already been downloaded).
I've downloaded under the same condition (same file host, same download server, same ISP) and I very very rarely get CRC error on straight download in the past. But after the last big JD update, I get this regularly. Don't get me wrong, I think JD is awesome, but this is a step back in terms of reliability from the previous version from what I've seen. As for the 'full sized file with .part'.. whenever I see that occurence, I almost always get a bad .rar when it's renamed. |
#31
|
|||
|
|||
The error comes undoubtedly from connection problems, from your connection, from the server, etc.
The message "no permissions to write..." is silly. But what I don't understand is why JDownloader can't just overcome these problems and finish the download. I remember using programs like getright and similar ones and they were just set & forget, they used to rollback some kbytes and the download always finished sooner or later. With JDownloader, when I come back to the computer, 4 o 5 files have failed, and I have to reenable or reset the files manually, sometimes, several times. Code:
EXCEPTION 57s.747 - SEVERE [java_downloader] -> SEVERE Exception occurred java.net.SocketException: socket closed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at sun.net.www.MeteredStream.read(Unknown Source) at java.io.FilterInputStream.read(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown Source) at java.nio.channels.Channels$ReadableByteChannelImpl.read(Unknown Source) at jd.plugins.download.DownloadInterface$Chunk.download(Unknown Source) at jd.plugins.download.DownloadInterface$Chunk.run0(Unknown Source) at jd.plugins.download.DownloadInterface$Chunk.run(Unknown Source) 57s.747 - SEVERE [java_downloader] -> error occurred while writing to file. socket closed 57s.748 - SEVERE [java_downloader] -> Error occured: ERROR_LOCAL_IO 57s.748 - SEVERE [java_downloader] -> A critical Downloaderror occured. Terminate... 57s.748 - SEVERE [java_downloader] -> ABBORTED BY USER 57s.748 - WARNING [java_downloader] -> Download not finished. Loaded until now: 103449318/103809023 57s.748 - SEVERE [java_downloader] -> Error occured: ERROR_DOWNLOAD_FAILED 57s.749 - SEVERE [java_downloader] -> ABBORTED BY USER 57s.758 - SEVERE [java_downloader] -> DOWNLOAD INCOMPLETE DUE TO FILESIZECHECK 57s.758 - SEVERE [java_downloader] -> Error occured: ERROR_DOWNLOAD_INCOMPLETE 57s.758 - SEVERE [java_downloader] -> DOWNLOAD INCOMPLETE DUE TO FILESIZECHECK 57s.758 - SEVERE [java_downloader] -> Error occured: ERROR_DOWNLOAD_INCOMPLETE 57s.759 - WARNING [java_downloader] -> Error occured- latest:ERROR_LOCAL_IO 00100000001001000000000000000001 <Statuscode 00000000001000000000000000000000 |ERROR_LOCAL_IO 00000000000001000000000000000000 |PLUGIN_IN_PROGRESS 00100000000000000000000000000000 |PLUGIN_ACTIVE 00000000000000000000000000000001 |TODO 00000000000000000000000000000001 |VALUE_ID_PREMIUM_DISABLE ErrorMessage: No permissions to write to hard disk 02m:27s.107 - WARNING [java_downloader] -> Resumepoint not valid 20m:03s.367 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 20m:37s.439 - FINER [java_downloader] -> load plugin: jd.plugins.decrypter.TbCm 30m:03s.333 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 40m:03s.299 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 50m:03s.265 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 1h:03s.231 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 1h:10m:03s.197 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB 1h:20m:03s.163 - INFO [java_downloader] -> ByteBufferController: Used: 0 B Free: 12.59 MB Last edited by briiii; 25.09.2009 at 03:16. |
#32
|
|||
|
|||
Indeed, I just queued up a ton of files in IDM, let that go, it lost connection a couple of times but resumed without issue (we are talking a big queue over 24 hours)
I then queued up the same files in jdownloader, what do you know? some no permission to write errors, and it couldn't resume. I love jdownloader because it has an awesome feature set that no other download manager has but it is failing in a pretty big area - the ability to resume a download. It can sometimes but too often it can't. I have been using download managers for years and never seen this problem before in any of them unless the server doesn't support resuming but in my case that isn't an issue. |
#33
|
||||
|
||||
Quote:
__________________
JD-Dev & Server-Admin |
#34
|
||||
|
||||
Quote:
__________________
JD-Dev & Server-Admin |
#35
|
|||
|
|||
my theory, the "No Permissions To Write To Harddisk" is a byproduct problem of the over active cpu problem. the cpu gets locked on whatever the problem we are trying to figure out. as a result of the excessive cpu usage JD loses track of the tcp or file write stream thus causing the write to hard disk error.
a temp work around is to put JD in low or medium priority (below normal) this will cause the OS to process file and tcp streams more often during cpu spikes thus limiting how the error occurs. also when the problem occurs use JD's reset option. sorry but you'll have to reDL the entire file. |
#36
|
||||
|
||||
Quote:
__________________
JD-Dev & Server-Admin |
#37
|
|||
|
|||
Today, i received this error too.
|
#38
|
|||
|
|||
Your hard disk is very probably working fine.
Typical recommendations, when you get this error message, are :- 1) Reduce the Max.Con. setting (bottom right corner of jD window) to 1. 2) Allow java and javaw in your firewall and virus software. 3) Disable the port 80/html/web scanner in virus software. 4) Un-install your firewall and reboot PC (this is safe when you've a firewall in your router). 5) Un-install virus software and reboot PC. 6) A torrent client is using too many connections; stop the client. 7) JRE version 1.6.0_17 ("**External links are only visible to Support Staff**) is 8) You've an unstable internet connection, contact you ISP. Please, implement these recommendations. If you still get the same error, please provide a detailed log. Look here for logging instructions. Last edited by remi; 28.01.2011 at 12:30. Reason: 1.6.0_17+21 |
#39
|
||||
|
||||
the *socket closed* bug should be fixed with new version
__________________
JD-Dev & Server-Admin |
#40
|
|||
|
|||
Bug was not fixed
Hello,
this bug still exists. have uploaded a log. http://jdownloader.net:8081/pastebin...e255e3a2393a59 most of the times you cant fix this error by resuming, you have to resest the file. i am downloading with 10 paralell downloads and 5 chunks. this error doesnt appear always, there appear to be bad days and good days. the last bad day before today was about 2 weeks ago, everytime else it simply works. cu acidburn |
Thread Tools | |
Display Modes | |
|
|