hda crashes when copying big files

[sven86]

I am trying to copy my avi files from one of my computers to my HDA via network in Windows 7. When I do that, it crashes my HDA and in order for me to access it again, I have to manually reboot my server. It does fine with small files, but it chokes on big files. My HDA is a Mediasmart EX475 with 2 GB of ram and an AMD +3800 chip.

Now I found out that any transfer over 150 MB it will cause it to crash. I can only transfer 150 MB or less at a time, which rules out any of my AVI movies. This is very inconvenient.

/var/log/messages

Code: Select all

May 1 01:46:21 localhost nmbd[1785]: [2012/05/01 01:46:21.174628, 0] nmbd/nmbd_browsesync.c:350(find_domain_master_name_query_fail) May 1 01:46:21 localhost nmbd[1785]: find_domain_master_name_query_fail: May 1 01:46:21 localhost nmbd[1785]: Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP. May 1 01:46:21 localhost nmbd[1785]: Unable to sync browse lists in this workgroup. May 1 01:46:52 localhost smbd[2218]: [2012/05/01 01:46:52.256090, 0] printing/print_cups.c:109(cups_connect) May 1 01:46:52 localhost smbd[2218]: Unable to connect to CUPS server localhost:631 - Connection refused May 1 01:46:52 localhost smbd[1810]: [2012/05/01 01:46:52.256684, 0] printing/print_cups.c:468(cups_async_callback) May 1 01:46:52 localhost smbd[1810]: failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL May 1 01:47:12 localhost dhcpd: DHCPINFORM from 192.168.1.3 via eth0 May 1 01:47:12 localhost dhcpd: DHCPACK to 192.168.1.3 (1c:6f:65:9e:35:16) via eth0 May 1 01:47:42 localhost smbd[2233]: [2012/05/01 01:47:42.051387, 0] printing/print_cups.c:109(cups_connect) May 1 01:47:42 localhost smbd[2233]: Unable to connect to CUPS server localhost:631 - Connection refused May 1 01:47:42 localhost smbd[2212]: [2012/05/01 01:47:42.052073, 0] printing/print_cups.c:468(cups_async_callback) May 1 01:47:42 localhost smbd[2212]: failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL May 1 01:48:18 localhost dhcpd: DHCPINFORM from 192.168.1.3 via eth0 May 1 01:48:18 localhost dhcpd: DHCPACK to 192.168.1.3 (1c:6f:65:9e:35:16) via eth0 May 1 01:50:04 localhost dhcpd: DHCPINFORM from 192.168.1.3 via eth0 May 1 01:50:04 localhost dhcpd: DHCPACK to 192.168.1.3 (1c:6f:65:9e:35:16) via eth0 May 1 01:50:23 localhost smbd[2212]: [2012/05/01 01:50:23.444716, 0] lib/util_sock.c:474(read_fd_with_timeout) May 1 01:50:23 localhost smbd[2212]: [2012/05/01 01:50:23.444956, 0] lib/util_sock.c:1441(get_peer_addr_internal) May 1 01:50:23 localhost smbd[2212]: getpeername failed. Error was Transport endpoint is not connected May 1 01:50:23 localhost smbd[2212]: read_fd_with_timeout: client 0.0.0.0 read error = Connection reset by peer.

Update: Adding more to this confusion is the fact that I can send big files through Mac OS X. What I was able to do was to use my Mac OS X Lion laptop to send files from my Windows 7 computer that has a RAID setup to my HDA without any problems. I have yet do a batch send, but this still makes no sense. It's fine with me if I had to use my Mac to transfer files, but this HDA isn't for me, it's for my brother. He doesn't have a Mac, so I really need some help in getting this problem to be fixed.

[bigfoot65]

Seems to me that someone had this problem before. Recommend you search the forums for a solution. It had something to do with a MTU setting I thought, but could be mistaken.

I understand this inconvenient, but likely not an Amahi issue. It is most likely a Fedora or hardware compatibility issue. I have heard of some having problems with the OS and these HP machines.

[sven86]

I already did a search but it was never resolved if I recall.

[sven86]

Okay, I changed the MTU from 1496 to 1024 and it's doing the same thing, what else could be wrong?

[bigfoot65]

Did you see this post?

http://forums.amahi.org/viewtopic.php?f ... 470#p18395

[sven86]

Yes I saw the post and I did everything in the post, still not working.

Another thing: I was able to upload my large files from a Windows XP VM fine. It's only Windows 7 that's causing the problem. I think it's a kernel issue, from what I've read in other sites, but I have yet found a clear, definitive answer to my problem.

I can only guess that the upgrade to Fedora 16 will probably fix the issue.

[sven86]

I found a way around it, I think.

I set up vsftpd in my console and created a chroot_list for the users I created in my HDA (through the Amahi web interface) so that they can stay within their home directory. Of course, when you do that, symbolic links to the public HDA folders (in /var/hda/files) won't work, so I had to create a files directory inside of the user's home directory and bind the /var/hda/files folder to it. Now I have access to the public folders on my ftp.

The second part is setting up Windows Explorer to access it. I clicked on the Computer icon in Windows Explorer and then I selected Map Network Drive. Then when the popup box appeared, I selected "Connect to a web service you can use to store your documents and pictures" That allows you to create a folder that access the FTP natively. I unchecked the "Log on anonymously" box and put in the username of the user that I have added the public folders in. After I created the folder, it will automatically try to open it. It will ask me my password and I checked in "save password" so that I can access it anytime. This is internal, so I don't really have to worry about security. Windows Explorer now sees the FTP folder as a native folder and I was able to upload big files without any problems.

I got one question, is it possible for the Amahi web interface to access a custom-made shell script after it creates a user? Because I want to create a shell script that will bind the directories in the created user's home folder, so I won't have to do it manually.

[bigfoot65]

Awesome. Is this something that might be reusable? Maybe it would be beneficial to others if you could document it in the wiki.

As for the script, how do you want the script to be triggered?

I am sure it's possible to program it into the Dashboard somehow, but the only simple way I can think of is via a web app. You would have to create a web app, then put the script in a folder called elevated in that directory. A index.php file or something similar would be created to execute the script with a button. This would allow the script to be executed as root user when activated by the button. This is a little crude and probably violates security, but it does work.