被VMware ESXi彈“Permission denied”支配過的運維應該不止我一個。半夜加虛擬機SSH過去密碼敲完屏幕上冷冰冰地顯示權(quán)限被拒絕切到vSphere Web Client上傳ISO、做快照同樣給你一句“權(quán)限被拒絕”。更抓狂的是同一句報錯搜索引擎能給你搜出上百種答案改密碼、重啟服務、重置配置試了一圈還是原地踏步。這篇文章我就把ESXi里各種“提示權(quán)限被拒絕”的真實場景全部拆開從SSH登錄、Web Client操作、數(shù)據(jù)存儲文件到vCenter接入按報錯出現(xiàn)的位置逐層理清根因和排查鏈路。里面提到的操作都是我在生產(chǎn)環(huán)境里實際踩過、驗證過的適合剛接手虛擬化的小白也適合被這類問題折磨過的老兵拿來對照。1. 先把“權(quán)限被拒絕”分清楚報錯場景決定排查方向很多人一看到“Permission denied”就慌了急著去猜密碼、改配置但ESXi是一個多層權(quán)限系統(tǒng)真正拒絕你的那一層可能和你想的完全不一樣。我自己的習慣是先不問“為什么被拒”先問“在哪被拒”。ESXi的權(quán)限體系至少有四個層面在同時生效主機本地用戶體系、ESXi對象權(quán)限模型用戶角色資源對象、vCenter SSO授權(quán)體系、以及底層文件系統(tǒng)的可寫性。同一個“權(quán)限被拒絕”可能發(fā)生在任意一層而且不同層的修復手段完全不一樣。我在日常排障時會把報錯場景先歸一下類下面這張表是我自己整理的報錯出現(xiàn)位置常見報錯原文根因方向SSH終端登錄Permission deniedplease try againroot密碼、鎖定模式、sshd配置、hosts.allowvSphere Web Client 登錄Access denied / Invalid credentials用戶名或密碼、域賬戶映射、會話過期Web Client 內(nèi)操作虛擬機Permission to perform this operation was denied對象權(quán)限、角色權(quán)限不足、鎖文件殘留數(shù)據(jù)存儲上傳/刪除文件權(quán)限被拒絕Datastore角色權(quán)限不足、空間不足、VMFS狀態(tài)異常vCenter 管理主機Permission denied / Failed to acquire credentialsvCenter授權(quán)、主機憑據(jù)失效、鎖定模式1.1 為什么同一句報錯根因會千差萬別ESXi沿用了Linux底層的一些設計但它真正管理權(quán)限靠的是“用戶 角色 對象”三層映射。你在vCenter里給某個用戶勾了“虛擬機管理員”角色并不意味著他能刪數(shù)據(jù)存儲上的文件你在主機上把root密碼改成新密碼但如果vCenter里保存的還是舊憑據(jù)vCenter發(fā)起的操作一樣會報權(quán)限被拒。所以我的建議是報錯信息只負責告訴你權(quán)限不夠不負責告訴你哪層不夠。排查第一步永遠是確認這個操作是誰發(fā)起的、在哪個界面上發(fā)起的、目標對象是什么。用SSH就是本地用戶體系在管用Web Client就是對象權(quán)限在管用vCenter就是SSO在管。把這一步定下來后面才能對癥下藥。1.2 一個很容易走偏的誤區(qū)我見過有同行一遇到權(quán)限被拒就把主機重啟結(jié)果問題還在——因為根本問題可能出在vCenter里的憑據(jù)或者數(shù)據(jù)存儲殘留鎖文件重啟主機壓根不影響這些。還有人在機房DCUI界面反復試密碼最后把賬戶鎖了連緊急救援通道都進不去。ESXi排權(quán)限問題的首要原則就是“最小動作”。在不清楚哪層攔截之前盲目重裝、重啟、重置密碼都是高風險動作尤其是生產(chǎn)環(huán)境。后面幾個章節(jié)我會按照不同的報錯位置把排查鏈路一步步寫出來。2. SSH登錄被拒的完整排查鏈路從服務配置到授權(quán)文件SSH登錄被拒是ESXi里最經(jīng)典、也最讓人火大的場景。密碼明明是對的屏幕卻告訴你Permission denied。按照我?guī)状闻耪系慕?jīng)驗下面這幾個位置按順序查基本能覆蓋90%的原因。2.1 第一步確認鎖定模式Lockdown Mode是否開啟ESXi有一個安全機制叫Lockdown Mode分成兩種Normal和Strict。Normal模式下root在DCUI還能登錄但從SSH、vSphere Web Client等遠程通道登錄會被直接拒絕Strict模式更狠連DCUI都拒絕root本地登錄只允許vCenter來管理主機。這個設計本來是防止密碼泄露后被人遠程登錄主機但它也經(jīng)常成為“權(quán)限被拒絕”的真兇。特別是有人為了應付安全審計在獨立主機上順手開了Lockdown Mode結(jié)果下次再要用SSH維護時發(fā)現(xiàn)自己根本進不去。排查方式不復雜。如果主機還能通過vCenter訪問可以在“主機 - 配置 - 安全配置文件 - 鎖定模式”里看到當前狀態(tài)如果vCenter也連不上只能去物理機DCUI確認。這里有一個我要特別強調(diào)的實操經(jīng)驗獨立主機沒有vCenter管理千萬不要開Strict模式。Normal模式出問題你還能靠DCUI本地登錄救回來Strict模式一旦觸發(fā)在沒有vCenter的情況下幾乎等于把自己鎖在門外。我在客戶現(xiàn)場遇過一次最后是廠商后臺介入才恢復代價非常大。2.2 第二步確認SSH服務和sshd配置是否被改過如果鎖定模式正常下一步要檢查SSH服務本身。ESXi默認SSH是關(guān)閉的如果服務沒啟動其實通常報的是“Connection refused”而不是“Permission denied”但有些客戶端對錯誤信息的處理很粗糙可能也會顯示權(quán)限類錯誤。開啟方法很簡單DCUI按F2進入Troubleshooting Options啟用SSH或者通過vCenter在“服務”里把TSM-SSH啟動。另外要重點檢查/etc/ssh/sshd_config這個文件。安全掃描總會建議把PermitRootLogin改成no把PasswordAuthentication也關(guān)掉。問題是這類改動在ESXi上很容易被某些動作意外覆蓋或者被手動改壞結(jié)果就是你拿著真實密碼也登錄不了反而像“密碼錯誤”。有一次我排障發(fā)現(xiàn)客戶主機上sshd_config里PasswordAuthentication被改成了no只有公鑰認證能用但管理員手頭又沒有對應的私鑰導致所有密碼登錄都被拒。最后是通過DCUI進控制臺把配置恢復成默認再重啟SSH服務才解決。如果你能通過DCUI或vCenter控制臺登錄主機可以這樣驗證# 查看SSH配置關(guān)鍵項 grep -E PermitRootLogin|PasswordAuthentication /etc/ssh/sshd_config # 改完配置后重啟SSH服務 /etc/init.d/ssh restart2.3 第三步root的authorized_keys權(quán)限和hosts.allow這兩種情況比較隱蔽但一旦發(fā)生就是那種“怎么試都不行”的頑固問題。先看authorized_keys。ESXi里root用戶的SSH公鑰存放在/etc/ssh/keys-root/authorized_keys。SSHD對密鑰文件權(quán)限非常敏感如果文件權(quán)限太寬松比如644、777或者所屬目錄的權(quán)限不對SSHD會直接忽略這個密鑰文件表現(xiàn)為“Permission denied (publickey)”。這不是密碼問題也不是用戶問題是SSHD出于安全策略自動拒絕了密鑰。再看hosts.allow。ESXi雖然精簡但保留了TCP Wrapper痕跡。如果/etc/hosts.allow里被寫入類似“sshd: ALL: deny”的規(guī)則那么所有SSH連接都會被拒絕而且日志看起來和普通認證失敗幾乎一樣不帶一點提示。這種情況我建議直接打開文件看一眼cat /etc/hosts.allow如果發(fā)現(xiàn)里面有deny規(guī)則按需刪除或注釋再重啟SSH。這個排查步驟因為過于“Linux老古董”經(jīng)常被做虛擬化的人忽略但它真實存在。2.4 第四步賬戶是否被鎖定ESXi對SSH登錄也有防暴力破解機制如果短時間內(nèi)連續(xù)輸錯密碼賬戶可能被臨時鎖定。表現(xiàn)就是你再輸入正確密碼也一樣提示Permission denied。這個時候檢查思路要變確認當前是不是連續(xù)失敗過多次。如果確實觸發(fā)了鎖定等鎖定窗口過去即可或者通過DCUI本地登錄重新操作。這里我不建議在生產(chǎn)環(huán)境用“重啟主機”來解賬戶鎖定代價太大。更正確的是平時不要反復盲試密碼一次失敗后先在vCenter或DCUI確認賬戶狀態(tài)再決定下一步。3. Web Client能開但操作全被拒會話、角色與對象權(quán)限的坑SSH排查完了另一種高頻場景是vSphere Web Client能正常登錄但一操作就提示“權(quán)限被拒絕”。這種問題通常和密碼無關(guān)而是ESXi的“用戶 角色 對象”權(quán)限模型在起作用。3.1 同是登錄密碼沒問題還是被拒有時候用戶輸入正確的域賬戶或本地賬戶Web Client卻提示Access denied。這種情況先排除瀏覽器緩存、會話過期等因素再考慮域賬戶映射問題。ESXi本地賬戶直接管理但如果你用的是AD域賬戶需要在ESXi上完成域加入和權(quán)限映射否則域賬戶就算密碼正確也默認無任何權(quán)限。常見表現(xiàn)是“能登錄但任何操作都被拒”本質(zhì)是用戶沒有關(guān)聯(lián)任何角色。解決路徑不復雜在“主機 - 管理 - 權(quán)限”里把域用戶添加進去并指定一個合適的角色。如果連登錄本身都被拒通常說明這個賬戶根本沒被ESXi識別或者密碼同步出了問題而不是權(quán)限問題。3.2 能登錄但操作被拒先看角色再看對象假設你在Web Client里建虛擬機、做快照、改配置每一項都報“Permission to perform this operation was denied”。這時我會優(yōu)先去“權(quán)限”頁面看當前用戶到底掛了什么角色。ESXi的權(quán)限模型是按“對象樹”展開的從數(shù)據(jù)中心、文件夾、主機到虛擬機、數(shù)據(jù)存儲每一層都能單獨配置權(quán)限。一個用戶可能在虛擬機列表上有“虛擬機管理員”角色但如果主機層沒有權(quán)限他在主機上創(chuàng)建虛擬機就會被拒如果數(shù)據(jù)存儲層沒有權(quán)限他上傳ISO、創(chuàng)建vmdk也會被拒。我把常見的操作項和對應需要的權(quán)限整理了一下排查時可以對照操作需要的典型權(quán)限上傳/下載數(shù)據(jù)存儲文件數(shù)據(jù)存儲 - 瀏覽數(shù)據(jù)存儲、分配空間、更新權(quán)限創(chuàng)建/刪除虛擬機虛擬機 - 創(chuàng)建、刪除主機 - 創(chuàng)建虛擬機開機/關(guān)機/重置虛擬機 - 交互 - 電源操作創(chuàng)建/刪除快照虛擬機 - 快照管理編輯虛擬機配置虛擬機 - 修改設備、修改資源配置自動啟動策略主機 - 配置自動啟動這張表不是官方的完整特權(quán)列表但足夠應對日常排障。你不需要把所有權(quán)限都背下來遇到報錯時先在對象樹對應層級查權(quán)限比反復猜原因高效得多。3.3 自動開機/來電自動啟動配置失敗的常見坑搜ESXi相關(guān)熱詞時很多人會搜“esxi設置虛擬機自動開機”“esxi來電自動啟動”。這個功能本身不涉及什么高級權(quán)限它藏在“主機 - 管理 - 系統(tǒng) - 自動啟動”里。如果你當前登錄的用戶沒有主機層級的管理權(quán)限點“編輯設置”后系統(tǒng)彈出來的就是權(quán)限類錯誤。更隱蔽的一個坑是即使你有主機管理員權(quán)限但ESXi主機上如果同時開了鎖定模式vCenter發(fā)起自動啟動配置也可能失敗。原因是自動啟動配置需要SSH或主機本地服務通道鎖定模式下這些通道被限制vCenter反而無法完成配置。所以如果你在配置自動開機時遇到權(quán)限被拒先去檢查是不是開了Lockdown Mode再檢查主機權(quán)限順序不要反。4. 數(shù)據(jù)存儲與虛擬機的“權(quán)限被拒絕”根子常在鎖文件這一類問題最有欺騙性因為表面上看是權(quán)限問題實際是文件和目錄狀態(tài)異常。我碰到的比例相當高尤其是發(fā)生過異常斷電、虛擬機強制關(guān)閉、HA故障切換之后。4.1 .lck鎖文件為什么刪不掉、刪了又報錯ESXi里每臺虛擬機開機時會在虛擬機目錄下生成.vmx.lck和.vmdk.lck之類的鎖文件正常關(guān)機后鎖文件自動清理。如果虛擬機異常退出或者你在開機狀態(tài)下強行刪除了虛擬機目錄鎖文件就會殘留。殘留的鎖文件會導致虛擬機無法開機提示“虛擬機文件已鎖定”或直接報權(quán)限被拒絕。這時很多人選擇手動刪除鎖文件但刪除時也可能被同一句權(quán)限被拒卡住原因在于當前登錄用戶沒有數(shù)據(jù)存儲層的文件操作權(quán)限。我的處理建議分兩步。先在數(shù)據(jù)存儲瀏覽器里確認鎖文件的名稱和位置然后給當前用戶臨時分配數(shù)據(jù)存儲的管理權(quán)限或者直接用SSH以root身份進入/vmfs/volumes對應路徑刪除鎖文件# 定位虛擬機數(shù)據(jù)存儲路徑 ls -la /vmfs/volumes/datastore1/ # 刪除鎖文件 rm -f /vmfs/volumes/datastore1/your-vm/your-vm.vmx.lck但這里有個極其重要的前提刪除鎖文件前一定要確認沒有其他ESXi主機或vCenter任務正在使用這臺虛擬機。在HA集群里虛擬機可能在主機之間漂移你以為它“沒開機”其實它正在另一臺主機上運行硬刪鎖文件會導致數(shù)據(jù)損壞。我個人的操作習慣是先SSH登錄每一臺可能運行該虛擬機的主機用esxcli查看虛擬機進程列表確認沒有開機記錄后再刪除鎖文件。4.2 .vmem內(nèi)存文件和“用戶拒絕訪問內(nèi)存文件權(quán)限”的問題搜ESXi相關(guān)問題時很多人會遇到“用戶拒絕訪問內(nèi)存文件權(quán)限怎么辦”這通常指向.vmem文件。vSphere里創(chuàng)建“包含虛擬機內(nèi)存”的快照時系統(tǒng)會在虛擬機目錄下生成一個和虛擬機內(nèi)存大小相同的.vmem文件。比如虛擬機分配了16GB內(nèi)存快照就會產(chǎn)生16GB的.vmem文件這個動作對數(shù)據(jù)存儲空間和目錄權(quán)限都有要求。如果你創(chuàng)建帶內(nèi)存快照時提示權(quán)限被拒絕先不要急著加權(quán)限先檢查數(shù)據(jù)存儲剩余空間。空間不足時ESXi可能返回權(quán)限類錯誤而不是明確的容量不足提示這算是ESXi本身錯誤信息不嚴謹?shù)囊粋€坑。確認空間充足后再給當前用戶補上“虛擬機 - 快照管理”和“數(shù)據(jù)存儲 - 更新權(quán)限”兩個權(quán)限點基本就能解決問題。另外如果你把虛擬機的.vmem文件下載到本地Windows機器上處理也可能被系統(tǒng)提示“拒絕訪問”那是Windows NTFS ACL的問題和ESXi無關(guān)。右鍵文件 - 屬性 - 安全把自己加進授權(quán)列表即可不要反過來去改ESXi端的權(quán)限方向錯了白折騰。4.3 VMFS文件系統(tǒng)權(quán)限r(nóng)oot為什么“萬能”還有一個容易混淆的點VMFS數(shù)據(jù)存儲上的文件ESXi Web界面操作走的是對象權(quán)限模型但SSH進入后你看到的是類Unix的權(quán)限位。很多管理員會拿“root在SSH里能訪問”來反推“用戶應該也能訪問”這個邏輯是錯的。SSH里的root是內(nèi)核級的超級用戶它訪問VMFS文件時會跳過權(quán)限校驗因此root能刪除、讀寫一切文件。但Web Client里的用戶權(quán)限完全由ESXi對象權(quán)限模型控制即使底層文件權(quán)限是755只要角色不對照樣權(quán)限被拒。反過來也一樣Web Client里能訪問的文件SSH里換個普通用戶可能還是被拒。理解了這一層你就知道為什么很多答案說“用SSH root去刪就好”而另外一些人堅持說“給了管理員角色還是不行”——因為兩邊根本不是在同一個體系里操作。5. vCenter接入與遠程操作權(quán)限拓撲和憑據(jù)失效vCenter環(huán)境下權(quán)限被拒的排查比獨立主機更繞因為多了一層“代理”。很多時候報錯的不是ESXi本身而是vCenter以某個身份去連接ESXi時被拒。5.1 把主機加入vCenter時提示權(quán)限被拒添加一臺ESXi主機到vCenter時vCenter會拿你填寫的root憑據(jù)去主機上做認證。如果賬號密碼正確但主機開了鎖定模式或者主機防火墻阻止了vCenter的訪問端口同樣可能報權(quán)限類錯誤。我的排查順序是先手動SSH登錄這臺主機確認root密碼可用再確認鎖定模式狀態(tài)最后在vCenter里重新輸入一次主機root憑據(jù)并讓vCenter重新驗證。很多時候問題就出在最簡單的憑據(jù)變更上——有人改過root密碼但vCenter這邊還存著舊密碼。5.2 vCenter用戶角色不足你操作的權(quán)限在哪個對象上vCenter里建了集群、數(shù)據(jù)中心、文件夾權(quán)限層層繼承。如果你的vCenter賬戶只在“虛擬機”層級有權(quán)限但你要在主機層級做維護、配置自動啟動、掛載存儲這些操作就會直接返回權(quán)限被拒。這種問題定位起來其實不復雜。在vCenter界面上你要操作的對象主機、數(shù)據(jù)中心、文件夾上右鍵 - 權(quán)限看當前賬戶是否有足夠角色。沒有就補上有就繼續(xù)往下查。大多數(shù)權(quán)限不足的問題在這一步就能解決不需要去翻日志。5.3 主機憑據(jù)失效所有遠程操作都會變成“權(quán)限被拒”這是我在生產(chǎn)環(huán)境遇到最多的一種情況。vCenter身上存著每臺主機的root憑據(jù)如果主機的root密碼被外部安全策略修改過vCenter不知道那么vCenter對主機發(fā)起的任何操作——巡檢、開虛擬機、裝補丁、遷移——都可能提示權(quán)限被拒。表現(xiàn)通常是你手動SSH能登錄主機vCenter上看主機狀態(tài)也正常但一發(fā)起遠程操作就報“Permission denied”。因為vCenter是拿它自己的憑據(jù)去認證的不是拿你界面上當前用戶的憑據(jù)。解決辦法非常直接在vCenter的主機對象上重新指定正確的憑據(jù)然后執(zhí)行“重新驗證”。跑一次主機掃描或任務確認憑據(jù)已同步即可。這個坑之所以隱蔽是因為它和ESXi本身的配置毫無關(guān)系純粹是身份憑據(jù)漂移問題。5.4 用esxcli遠程執(zhí)行命令被拒怎么辦有些朋友習慣在vCenter控制臺上通過SSH到另一臺主機執(zhí)行esxcli命令或者用腳本批量調(diào)esxcli操作主機。esxcli的大部分管理命令默認只有root或擁有特定角色的賬戶能用。如果報權(quán)限被拒先確認執(zhí)行賬戶是不是root如果非要用域賬戶必須先在主機權(quán)限里給該域賬戶分配“管理員”角色。另外esxcli命令如果通過vCenter執(zhí)行同樣受vCenter對目標主機的憑據(jù)影響優(yōu)先按照5.3的思路排查。6. 一次ESXi升級操作“權(quán)限被拒”的復盤鏈路理論講再多不如一個完整案例。去年幫一家客戶排過一次升級主機時反復報權(quán)限被拒的問題整個鏈路比較有代表性我把它完整復盤出來。6.1 現(xiàn)象與初始判斷客戶那邊通過vCenter給一臺ESXi主機安裝補丁任務中斷錯誤信息是“Permission to perform this operation was denied”。負責的同事第一反應是給當前vCenter用戶加權(quán)限加完再跑還是同樣報錯。于是問題升級到我這里。我先看了vCenter的任務日志確認失敗點在主機的補丁執(zhí)行階段而不是vCenter自身。這說明vCenter已經(jīng)把任務下發(fā)了但主機在認證或執(zhí)行時把vCenter的請求拒了。6.2 逐步排除我按順序做了四件事第一確認這臺主機有沒有開鎖定模式。通過vCenter進入主機“安全配置文件”狀態(tài)是“Normal鎖定模式”但客戶之前從未手動開過。這個狀態(tài)本身不會直接導致任務失敗但它會影響主機接受遠程命令的通道。第二SSH直接登錄主機用root賬戶手動跑一遍esxcli命令驗證主機本地權(quán)限沒有問題。esxcli能正常返回主機版本信息說明主機側(cè)命令執(zhí)行是通的。第三在vCenter里檢查主機的管理憑據(jù)。點開主機對象一看就知道問題了vCenter里保存的root憑據(jù)還是三個月前的舊字符串。客戶為了配合安全基線每個月跟主機root密碼變更但vCenter這邊沒有同步更新。第四更新憑據(jù)后重新驗證再跑升級任務順利通過。6.3 復盤結(jié)論這個案例說明一件很關(guān)鍵的事vCenter的權(quán)限拒絕有相當比例是“憑據(jù)失效”而不是“權(quán)限配置錯誤”。我遇到過很多人把權(quán)限模型翻了個底朝天最后發(fā)現(xiàn)只是密碼變更沒有同步到vCenter里。排查順序上先看vCenter里的主機憑據(jù)是否有效比去改用戶角色快得多。另外一個啟發(fā)是鎖定模式對vCenter操作也有影響但影響面沒有想象中大。關(guān)鍵在于主機是否處于鎖定模式以及vCenter當前角色是否有權(quán)管理該主機。如果你的環(huán)境里有安全策略要求開啟鎖定模式一定要同時確保vCenter的管理憑據(jù)和角色都正確否則日常運維會處處碰壁。7. 日常少踩“權(quán)限被拒”的幾條習慣性操作前面講的都是排障但作為運維更應該在日常運維里減少這類問題出現(xiàn)的概率。這里分享幾條我個人堅持的習慣算不上什么高深技巧但確實幫我省了很多事。7.1 給普通用戶分權(quán)限r(nóng)oot留作救急很多小團隊習慣所有人共用root結(jié)果每次權(quán)限問題都分不清是誰干的。我建議至少區(qū)分兩類賬戶一類是日常維護賬號權(quán)限按需分配能完成備份、開關(guān)機、快照等常規(guī)操作另一類是root只用于主機級安裝、升級、底層修復這種高風險的救急場景。這樣權(quán)限被拒最多發(fā)生在個別用戶身上不會影響整臺主機的維護通道。7.2 定期檢查鎖定模式和管理憑據(jù)我每個月做巡檢時會看兩項一是主機鎖定模式當前狀態(tài)二是vCenter里保存的主機憑據(jù)是否仍然有效?；▋煞昼娋湍鼙苊鈩e人半夜改完密碼后第二天vCenter所有任務全掛的局面。命令也很簡單SSH登錄主機后執(zhí)行esxcli system lockdown get esxcli system account list返回結(jié)果看一眼就夠。7.3 快照、升級這類高危操作前先驗證權(quán)限不要等到跑任務失敗才去查權(quán)限。在測試環(huán)境或非核心主機上先用同一賬戶跑一次快照創(chuàng)建、一次數(shù)據(jù)存儲上傳、一次esxcli查詢?nèi)椂纪ㄟ^后再對生產(chǎn)環(huán)境操作。這個小動作成本很低但能把大部分權(quán)限問題提前暴露掉。7.4 最后分享一個個人習慣我排ESXi權(quán)限問題時手邊常備一份操作和對應權(quán)限的清單就是第三章那張表的擴充版。每次遇到權(quán)限被拒我先不急著去猜而是把“操作 - 對象 - 所需權(quán)限”三個點對齊大多數(shù)問題在十分鐘內(nèi)就能定位。ESXi的“權(quán)限被拒”本質(zhì)上是一個信息模糊但指向明確的錯誤。只要你不慌按層排查它其實比很多無頭緒的故障好對付得多。希望這篇文章能幫你節(jié)省幾個本該安穩(wěn)睡覺的夜晚。