Photo files corrupted randomly

[Nick2253]

The DS380 - I don't mind drilling holes in it - but I already have the most expensive Noctua fans in it - even got a 140mm fit in the exhaust :D
I will try to increase the speed a little first then get back to drilling & modding.

I put high-end Noctua fans in my machine. Then I put super-high speed Delta fans in my machine. Then I added a divider next to the fans out of plexiglass to force the air into the drive cage! Nothing was effective.

Then I used my dremel to cut a 1/4" slot along the back of the drive cage. Sudden temperature drop.

Frankly, I don't think it's an issue of fan speed or CFM. It's just a bad design that needs more rear openings (I imagine that a half-dozen 1/4" holes will be as effective as my slot). There's just no way for the hot air around the drives to exhaust.

 

[shnurov]

Ok so I'm having a small concern - I am unable to connect to the CIFS share from my OS X client.
Followed this guide - but I guess I am missing out on something... unless that guide is Windows exclusive & I absolutely need to create users for OS X access?
https://forums.freenas.org/index.php?threads/cifs-windows-sharing-guide.20948/

Thanks Nick for the info - so venting something in the HDD cage on the back - where the connectors are? I don't need to make holes on the other side for exhaust.

 

[Nick2253]

Ok so I'm having a small concern - I am unable to connect to the CIFS share from my OS X client.
Followed this guide - but I guess I am missing out on something... unless that guide is Windows exclusive & I absolutely need to create users for OS X access?
https://forums.freenas.org/index.php?threads/cifs-windows-sharing-guide.20948/

When you try to connect, what happens? Are you getting a permission error? Is it telling you that the share isn't there?

You should not need to create users if you set up the share as open with guest access (I forget what the exact FreeNAS terms are). Don't forget that you need to check your dataset permissions.

Thanks Nick for the info - so venting something in the HDD cage on the back - where the connectors are? I don't need to make holes on the other side for exhaust.

Correct. You want to put the holes next to the connectors. I'd strongly suggest removing the backplane before drilling the holes to prevent stray pieces of metal from embedding themselves into the connectors and possibly shorting something.

See attached picture for an idea of the slots I cut. Like I said, a few holes would probably be enough.

 

[shnurov]

It gives the 'Access to your account on the server 'freenas' has been denied. Contact your sys admin.' error :(

 

[Nick2253]

That's a permissions problem. The share is likely otherwise working.

Under Services->CIFS, check what the Guest Account is set as. Mine is currently set to "nobody".

Under Storage->Volumes->[dataset]->Change Permissions, check what the permissions are set as.

Under Sharing->Windows (CIFS) Shares->[share], check if "Allow Guest Access" is checked. Make sure under "Advanced" that you don't have "Only Allow Guest Access" checked, and you don't have anything in "Hosts Allow" or "Hosts Deny".

EDIT: Also, make sure you haven't created an account on FreeNAS that matches your OSX username or ID. This may be causing a problem. If you have, just delete the account for now.

 

[shnurov]

I did all the above (except the hole drilling parts).

I tried putting Owner /user+group as 'nobody' as it was Guest prior to this.

Here's what my permissions look like, I don't have any accounts set up anywhere that match each other - wanted to avoid all that extra work for a private 'all access' office network.

https://www.evernote.com/l/ABzTFlEm5IRPaqWzMoi6MW81KWBD5HLyWKU

 

[rogerh]

This problem can apparently occur if you have ever accessed the share, or any other share on the same server, as a particular user other than 'guest'. If you can find a "connect as" button anywhere during the failed connection process you can try to set guest access in that. Or failing that try "nobody". If not, you have to find where OSX stores its passwords, and delete any for that server or share.

 

[dreamerns]

I've been having this same issue lately. I moved all my raw photos to freenas (once my ssd was full) and switched lightroom to use afp share. Since I do smart preview, I didn't notice any issues in the beginning until I started exporting my files. Then files would just randomly be corrupted. Ejecting the share and mounting it again would list some other files as corrupted. I tried copying those files from freenas to local osx and even if size would be the same, SHA hash would be different. rsync on the other hand would copy them correctly (even if I run rsync from afp share (not over ssh)). After switching to CIFS, I had no issues anymore. I tried to find why is this happening and found this article http://www.nicksherlock.com/2014/01/freenas-zfs-afp-filesharing-rsync-bad-idea/. Now, I did use rsync to copy files, but I did it over afp instead of ssh (I just prefer rsync to cp), so in my case this was not the issue. There is also bug reported here https://bugs.freenas.org/issues/10284. It seems that nettalk obviously has some weird issues and should be avoided.

 

[Glorious1]

Right, my impression is that the problem is in the netatalk implementation, not with AFP itself. That said, I have not found a corruption issue. The only issue I've found is when I copy large files from one folder to another on FreeNAS via AFP, sometimes the copy quits before it is done with no warning, and the file is not all there.

 

[Robert Trevellyan]

rsync on the other hand would copy them correctly

From the rsync documentation: "Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred ..."

 

[thenickdude]

I managed to track down this bug in netatalk/afpd and it'll be fixed in FreeNAS soon:

https://bugs.freenas.org/issues/10284

It's great being able to browse my photo library properly over AFP again!

 

[Glorious1]

I managed to track down this bug in netatalk/afpd and it'll be fixed in FreeNAS soon:

Wow, that is awesome. You've got to have some skills to get in that deep and find out what's going on! Thank you.

 

[leonroy]

Thanks for all the hard work to all who helped track down and fix this issue.

I've actually been experiencing it for the past year or so (never reported it - chalking it up to my own setup). In any case is there any possibility this bug caused write corruption to the files themselves?

Or does it simply receive an EOF on read only?

 

[thenickdude]

Yeah, as far as I can see, the bug could have caused the file to be closed during write too, truncating it.

I think Lightroom would have trashed JPEGs quite rapidly if it wanted to read them, update the XMP, and write them back, since it could have been interrupted during both the read and the write. I was lucky on my system to only be storing raws, so after the initial import, Lightroom didn't write them again and they didn't have a chance to be corrupted on the disk.

 

[leonroy]

Ugh, that's kind of depressing. Ironic since the whole reason I switched from Synology to FreeNAS was to take advantage of the robust error checking capabilities of ZFS. No good having awesome data integrity on the file system if your wire protocol is going to corrupt your data! ;)

Wonder how many corrupt files I might have since I keep my iTunes library, personal and financial files on the same NAS and access them via AFP.

I realize it's not FreeNAS's fault, but man that's a serious bug in Netatalk.

 

[thenickdude]

I keep VMs and videos on my FreeNAS, and haven't had any issues with those. Triggering the bug requires that the file doesn't have any extended attributes, and a request to list the file's extended attributes arrives while the file is open. I think that only certain apps are issuing those requests. Finder, Lightroom and Spotlight Search all seem to spam the directory with those requests (maybe polling for file changes or during thumbnail generation) but (for example) VirtualBox only seems to issue them before it opens the files, never during use.

I would only expect a financial file to end up truncated if you were to browse to the file's directory in Finder while the app was in the process of loading or saving. The time window where it could happen is short due to the smaller size of the file involved compared to a RAW file (and hence faster load/save times). If it happened during loading, most likely the app would just complain that the file was corrupt and not open it, leaving it untouched on disk where it would open perfectly on your next attempt. If it happened during saving, it's possible that the app would report the failure to save and allow you to retry, since it likely looks the same to the app as the disk filling up or detaching partway through writing.

iTunes music is probably virtually immune to corruption on disk, because I doubt it modifies the music files that frequently.

Some files have extended attributes and so were immune to the bug. For example, files downloaded by a web browser have a "quarantine" flag added by Mac OS which generates the "this app was downloaded from the internet, are you sure you want to open it?" dialog box. None of my Lightroom raws had extended attributes, though. You can run "xattr -l *" in a directory to list all the files which have extended attributes.

 

[leonroy]

Thanks for the description, that does put my mind a little more at ease. With iTunes though, I do occassionally fix the metadata in files which likely reads then writes back to the audio files.

In any case from your explanation it would seem at worst a handful of corrupted files might exist. Seems the bug's been present for about 12 months?

Guess I have ZFS snapshots from the past few years to fall back on, I better update them so they don't auto delete too soon! ;)