#dataontap

netapp server跟linux server做出來的檔案分享權限如果是以nfs為準，而不是cifs 那就是靠linux client實際產生出來的目錄、檔案權限 也就是linux 用帳號linuxuser (uid 1000)做出來的檔案目錄如果是 644跟755 windows要寫的帳號會落到other，所以就會沒辦法寫入、刪除

做法有兩種 I. 在linux client改寫入帳號的umask umask改成000那產生的檔案就是777

777的帳號跟目錄 windows自然可以寫

2. Server做user mapping netapp的做法是

（1）

假設存取分享的cifs使用者叫cifsuser

那就在netapp的/etc/passwd檔裡加一行

cifsuser:x:1000:1000:....

內容可以亂寫，格式要對就是了

總之重點就是uid那欄是1000

大家都是1000，那就可以雙向讀寫

（2）

在nfsv4環境中可能沒做nis server而用netapp本身去做user mapping

這時netapp裡已經一行linuxuser:1000

妳又不想在/etc/password多寫一行

那就要編輯/etc/usermap.cfg

讓通過認證的cifsuser變身成linuxuser

(說真的，會有人覺得編輯usermap.cfg比較簡單嗎？）

Linux nas server的作法也分兩個

（1）

如果samba帳號就是Linux os帳號

那當然就看samba帳號需要什麼uid號碼就建出同樣號碼的os帳號

不吃os帳號的samba帳號？我不知道samba帳號怎樣可以獨立於os之外，我連這個都不會，怎麼會知道到時候怎麼處理

（2）

假設有人就是這麼奇怪，想要cifsuser2通過認證後等於linuxuser

作法也是弄個user mapping 也就是在smb.conf中加一行

username map = /etc/samba/users.map

而這個檔案裡的內容要寫

linuxuser = cifsuser2

此外smb.conf中特定分享的 valid users 或 write list除了cifsuser2外也要把linuxuser寫進去

然後更妙的是這兩個帳號的密碼還要一樣

這問題搞很久

廠商都很廢，沒ㄧ個能打的

簡單來說就是大家要用同樣的字元

首先我們觀察到os disk可以有中文，但nfs磁碟就不能有中文，所以我們推斷netapp的volume或許要調整

data ontap 在產生vol時若沒有加-l 特別指定就會用預設的

第一個坑是用vol lang時列出的選擇就是只有左半邊，要utf8就要自己加.UTF-8

幹我ㄧ直選左半邊，難怪老是沒有utf-8

廢話講太多，因為怕未來忘記所以寫細一點

vol create <vol name> -l zh_TW.UTF-8

NA-oanas1*> vol lang zhtw_utf8

Volume language is zh_TW.UTF-8 (Traditional Chinese euc-tw with UTF-8)

Translation Versions        OEM Character set is cp950|cp950|Tue Jun 15 08:40:54 CST 1999

       NFS Character set is utf-8|utf-8|Fri Oct  2 06:00:53 CST 1998

第二個坑是volume預設options create_ucode convert_ucode某一個會是off的

所以當然就要把它們都設成on

vol options <vol name> convert_ucode on

對了，用putty測試時Translation -> remote character set要選成UTF-8

在瞎子摸象的過程中有人說nfsv4可以解決，我想應該是有道理，但沒有仔細試

Protocols in use　Volume language

NFS Classic (v2 or v3) onlyLanguage setting does not matter

NFS Classic (v2 or v3) and CIFSLanguage of the clients

Back in 2012 when NetApp first added SAN protocol support to clustered Data ONTAP I created a short video to show how easy and non-disruptive it is to move a volume (containing one or more LUNs) around in a cluster.  Although a bit dated, the feature is as powerful as ever!

From an operational perspective being able to move data without impacting users or reconfiguring clients is huge. If you want to re-balance for capacity or performance (including from spinning disk to hybrid to all-flash!), or replace hardware during a tech refresh, you can just do it!

It’s like VMware’s storage vMotion on steriods:  Any storage protocol, any client type, and your dedupe and compression and snapshot and replication and all the rest all keep working too.  Just one more feature in Clustered Data ONTAP!