Hi Guys,

I was moving some files from a drive outside the array (/mnt/disk/downloads) into the array and received a similar message in the syslog for each and every file I copied. As far as I can tell, the file has been moved, but these messages and "(39) Directory not empty" messages are troubling as I tend to see them for both iTunes and iPhoto libraries as well. I'm running unraid 4.5.6 and on a 10.6.4 Macosx client. Here is a sample:

shfs_setxattr: setxattr: /mnt/disk5/movies/The A-Team DVDRipï\200¨/i-ateama.avi (95) Operation not supported

shfs: shfs_rmdir: rmdir: /mnt/disk1/music/iTunes/iTunes Music/Janis Joplin/Unknown Album (39) Directory not empty
Sep 30 08:45:56 Clara-Belle shfs: shfs_rmdir: rmdir: /mnt/disk1/pictures/iPhoto Library/Import (39) Directory not empty
Sep 30 08:45:56 Clara-Belle shfs: shfs_rmdir: rmdir: /mnt/disk1/pictures/iPhoto Library/Import/Originals (39) Directory not empty
Sep 30 08:45:56 Clara-Belle shfs: shfs_rmdir: rmdir: /mnt/disk1/pictures/iPhoto Library/Import/Modified (39) Directory not empty
Sep 30 08:45:56 Clara-Belle shfs: shfs_rmdir: rmdir: /mnt/disk1/pictures/iPhoto Library/Import/Data (39) Directory not empty

 

Not sure what the \200 is at the end of the directory or if it matters, could be a space character.

 

This is what my smb-extra.conf looks like:

[global]
 security = USER
 guest account = nobody
 public = yes
 guest ok = yes
 map to guest = bad user
 map hidden = No
 map system = No
 kernel oplocks = no
 oplocks  = no
 level2 oplocks = no



[downloads]
 path = /mnt/disk/downloads
 read only = No

Did anyone ever figure this out?  I see the same Operation Not Supported message when I open and close iTunes.  Doesn't seem to cause any problems, but I would rather it not be there if possible.

I don't know if it's related, but Apple is notorious for extravagant use of file locks.

Hi,

 

I'm seeing this message every time Firefox downloads a file to my server.  Once for the .part file, and then again when it renames the file to the correct extension.

 

Windows only, no Macs, and so far nothing else I'm doing is causing these messages to appear.

 

Cheers.

And I am seeing the exact same thing... running 5b7

 

When saving from my Win7 system some files to the array - any file, the following comes up:

 

Jun 25 13:55:10 Tower shfs: shfs_setxattr: setxattr: /mnt/disk4/MyData/My Documents/2D76B268.tmp (95) Operation not supported (Drive related)
Jun 25 13:55:10 Tower shfs: shfs_setxattr: setxattr: /mnt/disk4/MyData/My Documents/demotivational-poster-14822.jpg (95) Operation not supported (Drive related)
Jun 25 13:55:14 Tower shfs: shfs_setxattr: setxattr: /mnt/disk4/MyData/My Documents/2807A93F.tmp (95) Operation not supported (Drive related)
Jun 25 13:55:14 Tower shfs: shfs_setxattr: setxattr: /mnt/disk4/MyData/My Documents/MinionMotivationalPoster.jpg (95) Operation not supported (Drive related)

 

System though does seem to work fine...

 

Shawn

 

Has anyone got any new clues on this? I have tried the samba config ideas related to file locking and for me too they seem to miss the mark.

 

In my case, the syslog entries are all results of Microsoft Office, and occur either with a manual "save" or with autosave. So quite a lot of syslog entries are generated when I have (as I usually do) a good six or more office documents open and active at the same time. All of this work resides on the unRAID box even when I am working with it.

 

As others have said, there doesn't appear to be any actual problem. I simply want a clean syslog! More importantly, it would just be nice to have an understanding of what is going on... or at least to know that someone smarter than me has an understanding of what is going on.

 

I am running unRAID 4.7, with no modifications or anything. Nothing fancy.

 

Here are a couple of example lines (the ..... are letters I've deleted).

 

Aug 11 14:24:06 Lemur shfs: shfs_setxattr: setxattr: /mnt/disk6/P...../Agenda 2011-07-21/440A0E90.tmp (95) Operation not supported
Aug 11 14:24:06 Lemur shfs: shfs_setxattr: setxattr: /mnt/disk6/P...../Agenda 2011-07-21/Agenda 21 July 2011.docx (95) Operation not supported

 

The puzzle for me (and I hardly know anything about this) is that it looks (to me) like an extended file attributes issue, and it seems like there shouldn't really be any trouble with extended file attributes with any recent form of linux.

 

Cheers,

 

Jason

I did a bit of experimenting just now and found something interesting.

 

If I open the file using a path such as \\Tower\Company\Meetings\whatever.docx, I can easily trip the setxattr error by manually saving the file, altering and saving it again, etc, to get a line like:

 

Aug 11 15:23:37 Lemur shfs: shfs_setxattr: setxattr: /mnt/disk6/Company/document.doc (95) Operation not supported

 

If I open the SAME file using a manually entered path such as \\Tower\disk6\Company\Meetings\whatever.docx, I cannot reproduce the error (or at least, not in a few minutes of trying).

 

It's physically the same file. I have no clue whatsoever as to why the error should occur via a user share but not via the disk6 type of access, but I hope it might mean something to someone and not just be a red herring.

 

As said this is a low priority thing in that it doesn't cause any problems in practice, still it is one of those things... you know... a "who is in charge here, me or the unraid box?" kind of thing.

 

 

the shfs (Share file system) did not support extended attributes.  I believe it was update in the most current beta to allow them, so this message should go away running the current 5.0b10

the shfs (Share file system) did not support extended attributes.  I believe it was update in the most current beta to allow them, so this message should go away running the current 5.0b10

Ya know, I never noticed that those messages went away with b10.

 

Cheers.

the shfs (Share file system) did not support extended attributes.  I believe it was update in the most current beta to allow them, so this message should go away running the current 5.0b10

 

Goodo! Thanks for the info. Now I know what the issue is I can just wait until an update fixes it. For my situation it is probably not worth upgrading to a beta version in order to get rid of these messages.

 

 

Yes, running the latest beta, 5b10, these messages are gone - my log goes back to July 31'st and not one entry...

 

Shawn