acurcione

@limetech Thank you for this! I was holding off upgrading from 5.0.5 until this came out of beta and this plugin worked perfectly. Not sure why others are having issues though. I stopped the array and backed up prior to running the commands though. Just in case! Anyway, thanks again!

Sorry to sound ignorant, but how exactly do I do that? And will I still be able to run BTSync in safe mode? Cause if not then I won't be able to do a test. I can say that now that I've moved the files to the array and off of cache I'm not getting these xattr errors. However I'm not trying to add anything new. If I do, even if it's just one file, I'll get these errors thrown in the logs for every file in that directory. It's freaking bizarre and I'm about ready to say screw it and find another way of backing up my audio files. Just don't quite understand why 4TB worth of video files have been syncing up for months, but audio files, not so much.

Attached. This is a fairly clean one too. I rebooted the server a few days ago as I was getting some odd hardware error, but no idea what. I even went in and ran a sync of the files in question, or at least a much smaller set of them. You'll see all the errors that are getting thrown when they're getting written (I'm assuming). Of course they're getting written to cache first (SSD) so keep that in mind. Let me know if anything jumps out at you. syslog.txt.zip

Bump... No ideas?

Anybody?? This problem has been driving me nuts! Honestly don't understand what these damn attributes are or why they only present a problem with my audio files (from iTunes).

And in case if anyone was wondering what kind of errors I'm getting in the unRaid syslog, this is what they are: Sep 4 15:11:07 Tower shfs/user: shfs_setxattr: setxattr: com.apple.FinderInfo /mnt/cache/Media/test/iTunes Media/Chaka Demus & Pliers/All She Wrote/10 She Don't Let Nobody.mp3 (95) Operation not supported Sep 4 15:11:09 Tower shfs/user: shfs_setxattr: setxattr: com.apple.FinderInfo /mnt/cache/Media/test/iTunes Media/Chaka Demus & Pliers/All She Wrote/11 Let's Make It Tonight.mp3 (95) Operation not supported

I've been having some trouble extended attributes using BTSync specifically. They did find and fix (allegedly) a problem that was found in some of my logs, but I'm still having some errors thrown in my logs. The developers stated this specifically: "As for uRaid log, please, check you file system and make sure that it has extended attributes enabled with the "user_xattr" mount option." I have no idea how to check to see if that is enabled, if it's enabled by default, how to enable it if it's not enabled, and whether or not I can do this with a running server with files. Can someone enlighten me on this? I'm running 5.0.5, BTW.

This is definitely a problem on the BTSync side. Sorry about that folks. No idea if/when I'll be able to get around this issue, but at least I know where it is.

Well this is getting more bizarre. Whatever the heck this thing is trying to sync is INSIDE the audio file. I don't understand this shit at all (see pic). I'm guessing that as more to do with BTSync than UR, but if anyone has any other ideas let me know. Until then, I guess I'm not backing this stuff up in the manner.

I'm on 5.0.5, BTW...

I'm trying to backup a large music/audiobook iTunes library and for some reason every time I try to do this I keep getting a ton of errors in the logs like this: Jul 17 16:58:49 Tower shfs/user: shfs_setxattr: setxattr: com.apple.FinderInfo /mnt/disk2/Media/music/iTunes Media/Vaya Con Dios/The Promise/07 The promise.m4a (95) Operation not supported I'm using BTSync to do the syncing just like I do with my movies/TV files and I've not had any issues. I actually copied all the files over via Finder the first time and then saw all these errors after I set up the Syncing so I deleted all the files, turned off the cache, and am trying to let BTSync move the files itself. Are these errors nothing to worry about or if they are, what the heck is causing them and how do I fix?

I have all 4TB drives in my setup on 5.0.5 with no issues at all.

I had a file move over this morning after mover ran so it wasn't picked up. I checked to see if the file (or any file) was open in my media directory and wasn't. So I ran it manually and it moved over fine. I'll check on this daily now and see if I can find the culprit if indeed it is an open file issue.

Shouldn't of. I'm using BTSync to keep files synced between servers and that last sync on one my shares was on the 11th. Now, I have no idea if it kept something open, but it certainly shouldn't have. I'm only syncing locally anyway.

So no explanation as to why it ignored files for several days than moved them? I'm just trying to understand this. I have it set to run daily and it runs daily, but it failed to move anything for several days. Why? I have it set to run daily on purpose to I'm not needlessly taking up space on the cache drive which has limited space anyway.

Other than not moving files that were on the cache drive for 5 days, yes. But it should have moved them on the 12th I believe based on timestamps when the files went up, oldest was on the 11th (morning time).

I was checking my logs today and noticed the mover script ran this morning (like it's supposed to do daily) and moved a bunch of files. The problem is most of them were copied to the server on the 11th. And today is the 16th. I went back through the log and mover ran every morning like clockwork on all the days in between, but for some reason missed everything that was there till this morning. No errors in the log anywhere about anything. One thing to note, and it may or may not be the issue, is that I added a drop_caches command before and after the mover runs as is noted elsewhere in the forum to help with memory consumption with cache_dirs. That's the only thing I've done. Just for clarity, this is what was added to the mover script right after "mover started" and before "mover finished" # Let's dump caches echo "dumping caches" echo 3 > /proc/sys/vm/drop_caches I saved the new mover file to /boot/custom/mover and added this to my go file: #Remove mover script and then link to custom version rm /usr/local/sbin/mover ln -s /boot/custom/mover /usr/local/sbin/mover Does anyone think any of the above could be the issue or is it possibly something else? I can post the syslog, but it shows absolutely nothing as far as errors. Just shows the mover running each time. Thanks in advance.

How does one go about modifying the mover script so the changes stick around after boot? I can't seem to figure this out... Never mind... I think I figured it out.

How does one go about modifying the mover script so the changes stick around after boot? I can't seem to figure this out...

Answering my own question - since I'm not using AFP at the moment and might not at all, I removed the shares. Shouldn't cause any issues at the present time.

OK. But I didn't create the "Network Trash Folder" or "Temporary Items" folders anywhere. I think those are auto generated by OS X or something? Can I remove all instances of those folders or will they just keep coming back?

I rebooted my server this morning and noticed these in my log when SMB was starting up. Apr 2 10:38:39 Tower emhttp: get_config_idx: fopen /boot/config/shares/Network Trash Folder.cfg: No such file or directory - assigning defaults Apr 2 10:38:39 Tower emhttp: get_config_idx: fopen /boot/config/shares/Temporary Items.cfg: No such file or directory - assigning defaults I don't think this is an issue, but just wanted to be sure. I'm guessing these are some kind of settings for Samba and if they're not found then defaults are assigned? Speaking of defaults, are those darn shares really needed?

In my attempts to find a simple yet affective way to keep data synced up between my Mac and unRAID I decided I'd try BTsync. Syncing using rsync seemed to be causing me fits, but that's another story. So I set it up and tested it before adding my tv and movie directories. Worked a treat so I added both my directories on my Mac and let that finish indexing everything. Then I added the tv directory to start. Since all but a few shows were already on unRAID I only expected it to add a few things, but it seemed to have change the date on all the directories under tv. No idea why though. I just started it on the movies directory after it finished tv and it did the same thing there as well. All directories have a new date on them (todays). Any idea why BTsync does this? And is it going to do this every time a file syncs? I sure hope not otherwise my drives are never going to spin down!

I'm not any longer. I think if it shouldn't be used, the option should be removed though.

Actually, I believe that Cache_Dirs still has a benefit for these users in that it pre-caches rather than waiting for your first access. My Movies collection is still small compared to many here. However, split across three drives, there is a delay of about 20 seconds on first access. For those who can keep their system up for months on end, this is a non-issue. However, if you experience multiple power outages a day, it is a significant aggravation. So are you using it with "scan user shares" set to yes or no then?