vfs ixnas errors with Mac Icon files - bug to report?

[statalently]

Hello there,
I have a FreeNAS serving SMB shares to mostly Mac Mojave clients.
The shares all have: catia, fruit, full_audit, ixnas, streams_xattr.

Since turning on full_audit, I receive a lot of errors in the logs:
freenas-wk smbd_audit: bsdacl4_2win: ixnas: pathconf() failed for <path>/Icon : No such file or directory

This seems to be to do with the Icon files in applications/plugins, etc. or, more likely, to do with the special character at the end which I believe is a CR.

My question is: Am I doing something wrong or should I file a bug report somewhere for handling of illegal characters in file names?

SMB Auxiliary params if you need them:

Code:

min protocol = SMB2
case sensitive = yes
strict locking = no
strict sync = no
ea support = yes
store dos attributes = no
map archive = no
map hidden = no
map readonly = no
map system = no
fruit:resource = stream
fruit:metadata = stream
fruit:encoding = native
fruit:wipe_intentionally_left_blank_rfork = yes
fruit:delete_empty_adfiles = yes
full_audit:prefix = %u|%I|%S
full_audit:failure = connect
full_audit:success = connect disconnect mkdir rmdir write read
full_audit:facility = local5

 

[anodos]

MacOS is creating filenames with a CR at the end of them? Can you zip up a sample file and send it to me?

 

[statalently]

PM sent! Thanks for looking into it!

 

[anodos]

I can only generate error if I switch encoding after writing data to share. In this case error message is expected because of the way that strings are being re-written on the fly.

 

[statalently]

Is this something to do with my settings for catia and fruit:encoding?

 

[anodos]

Is this something to do with my settings for catia and fruit:encoding?

There is nothing to do to get rid of the message really. You either write data one way or the other. You can't change encoding once data is written to the device. (well you can, but you will potentially get some errors). We will expose alternative character mappings in 12.0, but there will also be a GUI warning if users try to alter the setting on existing shares.

 

[statalently]

Okay, thanks for the information. Pardon my ignorance, but can you let me know the two ways of writing data you are referring to so I know what to go and research for for the future?

 

[anodos]

Okay, thanks for the information. Pardon my ignorance, but can you let me know the two ways of writing data you are referring to so I know what to go and research for for the future?

There are some characters that are illegal per NTFS / SMB. MacOS allows users to use these characters, but has to do something with them when writing to a remote SMB share. And so, MacOS converts the character into unicode private range and sends that name over the wire instead.
"fruit:encoding = native" converts these back to the original invalid characters when they are received. See manpages for vfs_fruit and vfs_catia for details.
For example, if you have "fruit:encoding = native", the Icon folder's last character will be 0x0D. If "fruit:encoding = private", the last character will be 0xF00D. If you change the parameter after writing data, then you end up with of file on disk with a name ending in 0xF00D but catia re-mapping 0xF00D to 0x0D before the pathconf(2) call, which results in a log message.

 

[statalently]

Samba Sensei!! Thank you for the information.

 

[anodos]

Samba Sensei!! Thank you for the information.

No problem. This is why changes to shares need to be carefully considered after data has been written.

 

[seanm]

MacOS is creating filenames with a CR at the end of them?

Oh yeah, this was from the pre-Mac OS X days, in Classic Mac OS when you added a custom icon to a folder, it was stored in an invisible file named Icon\r It was extremely common and such files survive to this day since there were so many of them.

 

[statalently]

this was from the pre-Mac OS X days

This still happens with Mojave (haven't tested Catalina) when you copy an image to paste as a folder icon in the Get Info window :(

 

[anodos]

This still happens with Mojave (haven't tested Catalina) when you copy an image to paste as a folder icon in the Get Info window :(

Yeah. This shouldn't be an issue though as long as you don't change the fruit:encoding parameter after data is written to the share. I merged in some xattr fixes for 11.3-U5 that should eliminate the log spam you were seeing in your other post. This particular log spam is correct though.

On a side note it appears there's a MacOS SMB bug in Catalina where it doesn't display icons on newly-copied files (does this even against a MacOS SMB server). Requires a refresh to display the file correctly. The decision to not have a refresh button in Finder is something I've always found mind-bogglingly dumb.

 

[seanm]

On a side note it appears there's a MacOS SMB bug in Catalina where it doesn't display icons on newly-copied files (does this even against a MacOS SMB server).

I repro this. Also just tried in the Big Sur beta and it's fixed there.

Requires a refresh to display the file correctly. The decision to not have a refresh button in Finder is something I've always found mind-bogglingly dumb.

A refresh button should never be necessary. Bugs like the above should simply be fixed.

 

[anodos]

A refresh button should never be necessary. Bugs like the above should simply be fixed.

Because there's never potential for notify response to get dropped or delayed? Or a client bug that sends a notify request too early (file doesn't exist) or too late (race between initial request for empty AFPInfo xattr, write of icon metadata, and notify request). I've seen recent MacOS SMB pcaps where they compound CREATE|READ|NOTIFY on xattrs. Seems ripe for a race depending on implementation. The fact that they tripped up on this on their own server/client implementation is an indication that maybe a refresh button isn't a terrible idea.