We have a failrly large volume/flexgroup which has NTFS set as security style. We map this from some of our Ubuntu servers using mount.smb3 (no special options)...
We would not like to have the Ubuntu servers run checks on some of the files and store a value in xattr, but we get an "Operation not supported"...
We are unsure if NetApp even supports this? And if at all on CIFS ? We have the option to mount via NFS instead (may cause other issues), but if we leave the security style to NTFS, will xattr work on NFS then?
...or maybe we need some special options on out mount command on the Ubuntu servers? Any help would be grateful... I know this is a very specific question which I might just forward to support... 😉
#Enable xattr on ONTAP?
oak junco
mighty palm
xattrs are not supported on CIFS. I don't think even Windows servers can do that? For xattrs to work withONTPA, you need NFS, and specifically NFS 4.2 since only there was xattr support implemented
on CIFS you should be able to utilize alternate data streams though (if that works on Linux? It does work from Windows)
i.e. filename.txt:streamname
oak junco
Yeah... just did a little test mounting the volume via NFS... and it seems to work... but then we have a little issue with special file/path names which are not shown the same if the filesystem is mounted via SMB3 or NFS... 🙂
But pretty sure xattr works on a Windows server share... not to be honnest I haven't tried it 🙂
mighty palm
what special file/path names? Usually that should work flawlessly if your volume language is set to something.UTF-8
oak junco
You know us in the nordic uses some strange chars, lile æøåÆØÅ 😉 and even if the language is set to da.UTF.8 (for Denmark) there are issues with other things... like we have a database which is populated from a Windows server who reads the filesystem, adds files/paths into the database, and we have had issues in the past wehere some files where not found if we just passed the file/path from the database to a Linux hosts with the filesystem mounted via NFS... this is the reason we use SMB3, even on the Linux hosts...
But this could also be due to Ubuntu 😉
mighty palm
hmm that sounds strange. I have never had similar issues with our own Umlauts (ÄÖÜ) over here. My guess is that at some point in the chain you're not using utf-8 and that causes issues (like the database fields or the scripts that populate it or something)... but it's hard to troubleshoot of course
but to be honest I have never set the volume language to anything other than C.UTF-8 for many years now... except to utf8mb4 in some cases where people think they need extra-fancy file names
oak junco
Ubuntu/Linux has always been a pain when it comes to language settings... I have given up trying to set it up to our language-style... whenever I try I end up enabling the whole OS to speak Danish back to me, which I don't like 😉
anyway, it seems to work on NFS, even with the security style set to NTFS.. and we only need the check-sums as xattr on Linux anyway (do find dupes)... I guess we will give it a try and see if it rakes havoc... we always have snapshots 😉
But "funny" story is that when the Americans created the ASCII standard, they forgot the Danish and Norwegian special characters... so they were mapped to [, , ], {, } etc.. it has been haunting us ever since... those damn Americans 😉
mighty palm
well, actually ASCII only defined the lower 7 bit, which are the same as in ISO 8859-1 🙂 but we have Unicode now for over 20 years so every software that doesn't use UTF-8 (or some other encoding) should be the one to blame 😉