fh_update dropbox errors on ReadyNAS NV+

That is very odd. You may wish to backup your data and do a factory default (wipes all data, settings, everything), then restore your data from backup.

Any add-ons installed?

You are correct. Dropbox is not available for the NV+.

I believe fh_update() is a function in nfsd (the linus nfs server) http://lxr.free-electrons.com/source/fs ... sfh.c#L584

There's an old patch (~2006) which references the "already up to date!" warning here: http://lkml.iu.edu/hypermail/linux/kern ... /1241.html
It's apparently been applied to the free-electrons version of the modules in the first link. But perhaps the Readynas NV+ kernel predates that change, and it might not have been any reason to backport it.

So I suggest that you look in any shares that are enabled for nfs, and see if any include a hidden .dropbox folder. Perhaps run your find command over the full data volume.

mdgm - no plugins installed at all and I've turned off or removed all the optional plugins that come with the firmware (and the whole system is behind a firewall).

StephenB - There are definitely .dropbox dirs/files on the nfs shares -- these are generated by the client machines when users run the linux dropbox client, which is common. The NV+ is serving up linux home directories for my lab. This would mean that fh_update in nfsd is generating a kernel error message, but exclusively when reading|writing these dropbox files. Sort of makes sense as to where the error messages are coming from and confirms it's not some sort of rogue dropbox server running on my raid, although doesn't explain why fh_update has problems with stuff in the .dropbox directories. I'll poke around a bit more and see if I can figure out exactly what fh_update is doing. These are not the actual dropbox data dirs, but rather the internal state info..

Thanks!

mazerj wrote:

StephenB - There are definitely .dropbox dirs/files on the nfs shares -- these are generated by the client machines when users run the linux dropbox client, which is common. The NV+ is serving up linux home directories for my lab. This would mean that fh_update in nfsd is generating a kernel error message, but exclusively when reading|writing these dropbox files. Sort of makes sense as to where the error messages are coming from and confirms it's not some sort of rogue dropbox server running on my raid, although doesn't explain why fh_update has problems with stuff in the .dropbox directories. I'll poke around a bit more and see if I can figure out exactly what fh_update is doing. These are not the actual dropbox data dirs, but rather the internal state info..

I think that is the basic explanation. The original patch URL I sent before said these "errors" were false alarms.

There is a perfectly valid situation where fh_update gets called on an already uptodate filehandle - in nfsd_create_v3 where a CREATE_UNCHECKED finds an existing file and wants to just set the size. We could possible optimise out the call in that case, but the only harm involved is that fh_update prints a warning, so it is easier to remove the warning.

I can imagine a dropbox client doing something like that.