[Solved] JDownloader in vmware machine has problems with host shared folders

I created a vmware Windows 7 machine for the purpose of controlling my downloads and torrents from afar (the current web interface doesn't cover all my needs).

I've tried several configurations but I always face the same problem. When I try to download a file with JDownloader to a host shared folder (something like \\vmware-host\shared folders\D\infiles ) I can get the download working but when it ends the file is grayed out in the jdownloader interface.
If I check the folder the file is there but is named with a .part extension in the end.

It seams that jdownloader cannot rename the file. I don't think it's a permisions error since I can manually rename them within the virtual machine and then I can ask jdownloader (after reactivating the links) to extract the files (and finally delete the rared files as I have configured).


A workaround is to use a temp folder in the virtual drive for the downloads and then set the unrar plugin to extract to the final folder. This works for me because I have another program that copies the files from this final folder to its corresponding destination (I download mainly tv shows).

But I guess this workaround wouldn't be good for everybody.

jdownloader is the only program I use that has problems with the host shared folders in the vms. Torrent programs don't seam to have the same problem.

Hi

I just read a post of some other user who wanted to try to write to a network drive.

I did not test this, as my windows installation has no rar nor JD, but I guess it could be related to the path being a network path. Try assigning a drive letter to the network path in VMWare and then selecting that as JD Download target.

It's already like that. I created a Windows Drive connection to the path I needed so the configuration in jdownloader is like this:

D:\infiles

Thanks for your quick response.

PS- Also let me clarify that the problem is not derived from the use of rar files. The problem is that jdownloader cannot rename the .part file to the real downloaded file name.

.part files are files that haven't finished downloading. You should wait or Resume those files. If they can't be resumed you must Reset them.

Thanks for the infor remi, but I already new that.

The problem is (as I said in my first post) that when jdownloader finishes downloading each file it cannot rename it for some reason.
In the donwload list it leaves them grayed out (stopped) with no error message.
Resuming is not an option. Enabling does nothing and reseting obviously starts all over again with the same ending.

Thanks for your response.

Allow java and javaw in your firewall and virus software. Also disable (or un-install) the port 80/html/web scanner in your virus software.

If this doesn't help, please un-install your virus. Special software and registry cleaners might be needed.

If un-installing the virus doesn't help, please provide a complete and detailed log.

java allowed in the firewall (even tried with firewall deactivated) and no antivirus software.

I'm at work now. I'll get the log file this evening.

Thanks for your time.

[Jiaz]

you must use drive letters like c:\ or so.
\\dadad format does not work under windows at the moment, because we use commandline version of unrar in stable

I'm sorry if I'm harsh Jiaz, but I would suggest to read the full thread before posting, and more importantly before marking it as SOLVED, cause it is not.

Originally Posted by jurrabi

It's already like that. I created a Windows Drive connection to the path I needed so the configuration in jdownloader is like this:

D:\infiles

Thanks for your quick response.

PS- Also let me clarify that the problem is not derived from the use of rar files. The problem is that jdownloader cannot rename the .part file to the real downloaded file name.

As I said, three times now. The problem is not related to rars. It happens also with avi files and any other file type.

The problem is that jdownloader can write to the network drive with a drive letter assigned, but when it finishes downloading it can't rename the .part file to the real name.

Also I think it might be related to how vmware do host shares because I've used jdownloader in the past with network drives without problem.

I'm not even saying this is a jdownloader problem. I just posted to check if someone with a similar configuration has run into the same kind of problems and how they solved them (if they could).

Thanks for your response.

I was able to connect to the virtual machine from work (Isn't that nice?) and retrieve the log.

As I suspected there is a problem when renaming:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

The ERROR_LOCAL_IO indicates that the renaming fails for some reason.

Permissions is not the problem because from within the virtual machine I can rename files in the explorer (using the same user jdownloader uses).

Also I found out that this same problem was reported before (http://board.jdownloader.org/showthread.php?t=22436) and also Jiaz participated, but the problem wasn't figured out (just worked around like I did saving to a local virtual machine drive).

I don't know if there are more than one ways to rename files in java, but clearly the one used in jdownloader doesn't agree with vmware host shares.

Don't bother with the answers "jdownloader is working for everybody for more than xxx years"... Not interested in a bad Statistics-philosophical argument.

The fact that other programs work fine with vmware shares and jdownloader don't shows that there is a way for it to work. And people would benefit from it if it was found.

Thanks for all your time. I'm done now.

PS. also please don't ask for a full log... what is needed is there. If someone interested in solving the problem wants to follow the issue (that is not solved) it is easy to reproduce. IT FAILS ALWAYS WHEN TRYING TO SAVE FILES TO A VMWARE HOST SHARE.

[Jiaz]

you must mount the \\xyx folder to a drive like z:\\
java/windows failes in renaming a \\xyxy\test.rar file

Hi

I just tried to reproduce this error, because you made me become interested in this.

While my host system for VMWare is Windows XP, I installed a copy of Windows 7 inside a virtual machine, setup JDownloader, and tried saving to a Network Drive mapped to the vmware-host share.

unfortunately this seems to work fine for me, so I guess the error is not within JDownloaders responsibility.

I used:
Host:
Intel Core i3 - 4GB Ram - Windows Xp 32bit/en
VMWare Workstation 7

Guest:
Windows 7, 2 Cores allocated, 2 GB RAM, vmware-tools installed.
I used the most recent JRE from (http://www.java.com/en/).
I used JDownloader Offline installer Package.
I mapped vmware-host to drive y:, shared folder was U:\incoming(which is my default JD Folder on the host). Please note that U:\ is also a network share to my secondary development server in my local network.

I added a package of fileserve links to JDownloader, and let it download.
After the downloads finished, it unrared successfully, the extracted files passed an MD5 checkup.

So sry 4 that, but I was not able to reproduce your bug. But considering that my Configuration is pretty much the same except I guess you are probably running a W7 host and that my downloads go onto another network share, I suppose the error might be related to your win7 host/file system rights(YES, I read that you can rename files from within the explorer inside the virtual machine.).

What I would suppose for now is that you create a folder on your host system, make sure you set full access for all users(including extended ACLs), share that folder manually with the win7 integrated tools, and try to use that manually created share from within VMWare as JDownloader target path.

Also, If you are not using VMWare Workstation but instead VMWare Player, try to get a copy of VMWare Workstation (from **External links are only visible to Support Staff**www.vmware.com ) - believe me, it´s worth every Dollar I've paid for it so far. Also Workstation has way less glitches than Player.

Thanks a lot for a very very informative post.

I agreed with you that the differences between the host windows version should not be an issue.

Knowing that this works for some people I'm going to keep testing.

As you suggest it all seems to be permissions related (although right now I can't guess why).

Permissions with ntfs file systems and windows are many times a pain in the ass (how beautiful is unix).

Initially I tested what user was using VMWare (Workstation, I also have been using it for years) and found out It was mine (the permissions of the user that launches vmware).
I checked that I had full rights in the selected folders.

I also shared a folder within the C drive (just to avoid any drive that has jumped through several installations and have historical permissions for other systems) but same result.


One question: what are extended ACLs?

I'll keep testing and promise to post if I find out something useful.

Thanks a lot 4nt4r3s


@jiaz... I'm starting to think that you are a bot.

Originally Posted by jurrabi

@jiaz... I'm starting to think that you are a bot.

Wow. That would be a huge breakthrough. jD developed by an extremely intelligent bot.

BTW, your joke is nominated for "joke of the year"! LOL.

when I wrote of extended ACLs I meant ACL=Access Control List, and with extended I considered additional rights besides r/w/x, such as "Show Folder Content", "Modify, "Special permission" and "NTFS Meta Stream extended permissions".

Maybe the real names do differ in Windows, I just kinda translated them on the Fly, as I am at work right now, and they only have german windows versions.

Hello,

I have exactly the same problem as jurrabi :
I have a virtualbox (windows 7) running JDownloader and the download folder was a network drive (UCN path: \\VBOXSRV\...) and although the files are fully downloaded, the files are not renamed (extention .part remain).

As advised on this post, I have now mapped this network drive to have a drive letter and I changed the download directory. But unfortunately it didn't help: on 7 downloaded files (on rapidshare), only the very first file was correctly renamed (.part extention removed). All the other files are OK (I could uncompress them after renaming them). In JDownloader, the lines are greyed out and the status is > CRC Check running (MD5)...

[drbits]

My recommendation is to download to a local drive and extract to the UNC path. Actually renaming files using a UNC path does not always work as expected in Windows.

Regular files are not automatically moved after they are downloaded, only RAR archives (in Stable). You will have to move the files manually. A feature request has been submitted to fix this in a future version.
_________________________________

If you have a problem, regardless of the problem, follow the rules and provide sample links and a log. In this case, you would also provide directory names and the versions of the software in use.

It is also possible to set the protections of a directory to allow creating and writing to files, but not renaming the file. Make sure your virtual user has "Full Control" privileges on the directory that the files are being written into. This is not always easy if you do not have a domain server. Make sure the user in the Virtual machine has an account defined on the remote computer.