Am Sonntag, 29. Juli 2012 schrieb Mark Fletcher: > Ahoy the list! Hi Mark,
> I use a Buffalo 4TB NAS using RAID which I mount from my Debian Wheezy > AMD64 running on a self-built Intel Core i7 920-based machine. > > I want to be able to read and write the NAS from the Linux machine > with minimum fuss. I also run a virtual Win7 guest on my Linux host, > and want to be able to access the NAS from there also. I explicitly > mount the NAS from the Linux host when I want it, and just access it > from the Windows guest using Windows Explorer by referring to the NAS > by its network name. I wouldn't _object_ to being able to auto-mount > the NAS on boot of the host, as long as doing so doesn't cause untold > hassle if the NAS is not available. > > One purpose of having the NAS is a place to store backups as > protection against disk crashes on the Linux host, VM disasters, etc. > > Currently I mount the NAS on my Linux box using the following command > as root. I am wondering if there is something wrong with this command > as I will explain in a moment: > > mount -t cifs <network path of NAS>/share -o guest /mnt/nas > > After having done this, I can read data on the nas as any user by > referring to /mnt/nas. It seems that to write I have to be root, which > is inconvenient and something I'd rather avoid but not a disaster. It might be that the Samba server on the NAS – I bet Buffalo uses Samba here – might not return ownership information. In that case, you can make all files owned by a certain user with the uid/gid mount options. See manpage of mount.cifs. > The issue is this: It seems that data I write there after mounting is > not maintaining 100% fidelity. Here's an example: > > Dump a mysql database I have on my Linux host: > > mysqldump yahdahyahdahyahdah > /opt/recovery/mysql20120725.sql > > Then bzip2 the puppy: > > cd /opt/recovery > bzip2 mysql20120725.sql > > Test the correctness of the archive > bzip2 -t mysql20120725.sql.bz2 > > (One time I also extracted it all again to a different directory and > diffed with the original to make sure it was good and could be > extracted back to the original) > > This produces a demonstrably-correct compressed archive of my db > backup, about 150MB in size. > > Now copy that to the NAS: > > cp mysql20120725.sql.bz2 /mnt/nas/dbbackup > > (directory /dbbackup already existed on the NAS) > > That copy operation results in a file on the NAS that is identical in > size to the one I copied. > > cd /mnt/nas/dbbackup > > bzip2 -t mysql20120725.sql.bz2 > > ... results in a failed test saying the archive is corrupted. Fair > enough, I thought, perhaps bzip2 doesn't like operating over the > network. So I then copied the backup file back to a different location > on the host, bzip2 -t 'd it there, and got the same error. Could you please try it that way: dd if=/dev/zero of=lotsofszeros bs=1M count=10 sha1sum lotsofszeros cp lotsofzeros /mnt/nas/ sha1sum lotsofszeros With hd or xxd you could get a hexdump. If the issue does not trigger with zeros, then use sha1sum your database backup file and then copy it and sha1sum it again. Thats just to verify the whole thing a bit more. Just to make sure also copy the file locally and verify sha1sum. It might be an issue local to your client. > It looks like what got stored on the NAS is not exactly what was > originally on the host. This is a huge problem for me as it means I > can't rely on backups dumped on that device. Is there something wrong > with the way I am mounting the NAS that is leading to this? As you have Wheezy I assume you use kernel 3.2. As to what I have seen that is stable with CIFS, but I didn´t specifically test for data integrity either. But the Buffalo NAS might be using some real old stuff. I doubt they would sell something that doesn´t store data correctly. But it might be… I would check whether there is a firmware update. If that does not help I would check what the Buffalo NAS has to say about the RAID integrity and the harddisks. If thats okay, then you may consider putting a Debian onto the NAS. As to my knowledge this should be possible at least with certain models. But I am not sure whether only chroot or a complete replacement is possible. A complete replacement would be better in order to get a more recent kernel onto the box. (Now thats why I want something that I can install Debian too and do it all by myself.) Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201208012104.09407.mar...@lichtvoll.de