中文版請見本文最下方的「中文版」摺疊區塊。
Applies to: Ambedded UVS Manager (SMB / CIFS service on a Ceph cluster)
Scenario: The SMB service is joined to an Active Directory domain
Symptoms
When a Windows client connects to a specific node using \\<node-ip>, an "Enter network credentials" dialog appears, and authentication fails even with correct credentials. The shared folder cannot be opened. SMB connections to all other nodes in the cluster work normally — this is the key identifying characteristic, indicating the problem lies with the service on one node rather than with the domain or the cluster-wide configuration.
A second symptom is broken name resolution. Running ls -l /srv/share/ inside that node's SMB container shows numeric UID/GID values instead of domain accounts for some directories:
$ ls -l /srv/share/ total 0 drwxrwxrwx+ 18 90298892 90200514 16 Jul 30 15:45 <SHARE_A> drwxr-xr-x+ 4 <DOMAIN>\<user> 90200514 2 Jun 4 2024 <SHARE_B> drwxrwxr-x+ 2 90298892 90200514 14 Jul 29 20:21 <SHARE_C>
Diagnosis: Confirming This Is the Same Issue
Step 1: Compare smb.conf on the failing node against a healthy node
Inspect smb.conf inside the SMB container on both nodes, focusing on the [global] section. The failing node is missing the entire domain-member configuration:
[global]
clustering = yes
ctdb socket = /var/run/ctdb/ctdbd.socket
logging = file:/dev/smbcon
log file = /dev/smbcon
log level = 3
max log size = 0
debug timestamp = no
netbios name = <NETBIOS_NAME>
netbios aliases =
security = user
unix charset = UTF-8
kerberos method = secrets only
ntlm auth = true
idmap config * : backend = autorid
idmap config * : range = 90000001 - 100000000
allow trusted domains = true
directory mask = 777
create mask = 777
...A healthy node looks like this:
[global]
clustering = yes
ctdb socket = /var/run/ctdb/ctdbd.socket
logging = file:/dev/smbcon
log file = /dev/smbcon
log level = 3
max log size = 0
debug timestamp = no
netbios name = <NETBIOS_NAME>
netbios aliases =
realm = <AD_REALM>
workgroup = <WORKGROUP>
server role = member server
security = ADS
unix charset = UTF-8
kerberos method = secrets only
ntlm auth = true
winbind use default domain = false
winbind enum users = true
winbind enum groups = true
winbind cache time = 7200
winbind max domain connections = 10
winbind request timeout = 60
idmap config * : backend = autorid
idmap config * : range = 90000001 - 100000000
idmap config * : sssd_compat = false
idmap config * : unix_nss_info = yes
allow trusted domains = true
directory mask = 777
create mask = 777
...There are four differences: security has fallen back from ADS to user; the three lines realm, workgroup and server role = member server are gone; all winbind parameters are gone; and idmap config * : unix_nss_info = yes is gone. Seeing security = user on the failing node while a healthy node shows security = ADS is enough to identify this issue with reasonable confidence.
(The remainder of both files is identical across nodes and unrelated to this issue, so it is abbreviated as ....)
Step 2: Check the SMB container log
The log shows two classes of errors matching the two symptoms above. Authentication stage (the credential prompt):
check_sam_security: Couldn't find user '<user>' in passdb. check_ntlm_password: Authentication for user [<user>] -> [<user>] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1 gensec_spnego_server_negTokenTarg_step: SPNEGO(ntlmssp) login failed: NT_STATUS_NO_SUCH_USER smbd_smb2_request_error_ex: ... status[NT_STATUS_LOGON_FAILURE] || at source3/smbd/smb2_sesssetup.c:147 Server exit (NT_STATUS_CONNECTION_RESET)
Name resolution stage (numeric UID/GID):
[nss_winbind] Winbind external command GETPWUID start. Search UID 90298892. Failed with NT_STATUS_NONE_MAPPED. Could not convert sid S-1-5-21-<...>: NT_STATUS_NONE_MAPPED wb_lookupsid_recv failed with NT_STATUS_NONE_MAPPED.
NT_STATUS_NO_SUCH_USER occurring together with NT_STATUS_NONE_MAPPED is the characteristic signature of a node that has dropped out of domain membership.
Cause
The SMB service on that node experienced a disconnection. When the service reloaded afterwards, it applied a configuration that did not include the domain-member settings and fell back to local (security = user) authentication — which is why the Windows client is prompted for credentials and always fails. At the same time winbind is not active, so domain SIDs on files cannot be mapped back to account names, leaving only numeric UID/GID in ls -l.
This is a service-state problem confined to one node. Neither the cluster configuration nor the Active Directory settings have been altered.
Resolution
Log in to UVS Manager, go to the SMB cluster page, select the SMB service on the affected node, and click Restart. Once the service returns to a normal state, reconnect from the client.
Verification
Connecting to \\<node-ip> no longer prompts for credentials and the share opens directly; smb.conf inside the container has security = ADS along with realm / workgroup / winbind settings restored; ls -l displays domain account names correctly.
FAQ
Will the configuration be lost again after the restart?
No. The correct configuration is distributed from the cluster, and the SMB service retrieves the full set of settings — including domain membership and winbind parameters — when it restarts.
Can I restart the SMB container directly from Cockpit Docker Manager?
Please use the Restart function on the UVS Manager SMB cluster page instead. That path handles the service through the cluster workflow and is the safer, more consistent option.
Do I need to edit smb.conf manually or run any ceph commands on the node first?
Neither is necessary. smb.conf is generated by the system; manual edits inside the container will not persist and are not recommended.
If the Problem Persists
Contact Ambedded technical support and provide: the UVS version, the IP of the affected node, a side-by-side comparison of smb.conf from the affected and a healthy node, an excerpt of the SMB container log, and a screenshot of the client error.
▶ 中文版 Chinese Version（點此展開／收合）
適用產品：Ambedded UVS Manager（Ceph 叢集 SMB / CIFS 服務）
適用情境：SMB 服務已加入 Active Directory 網域
症狀
從 Windows 用戶端以 \\<節點IP> 連線某一台節點時，跳出「輸入網路認證」視窗，輸入正確帳號密碼仍然驗證失敗，無法開啟共享資料夾。叢集中其他節點的 SMB 連線一切正常——這是本問題最重要的辨識特徵，代表問題出在單一節點的服務，而不是網域或叢集整體設定。
另一個伴隨現象是名稱解析異常。進入該節點的 SMB 容器執行 ls -l /srv/share/，部分目錄的擁有者與群組會顯示成純數字，而不是網域帳號：
$ ls -l /srv/share/ total 0 drwxrwxrwx+ 18 90298892 90200514 16 Jul 30 15:45 <SHARE_A> drwxr-xr-x+ 4 <DOMAIN>\<user> 90200514 2 Jun 4 2024 <SHARE_B> drwxrwxr-x+ 2 90298892 90200514 14 Jul 29 20:21 <SHARE_C>
診斷：確認是否為本問題
步驟一：比對故障節點與正常節點的 smb.conf
在兩台節點的 SMB 容器內查看 smb.conf，重點看 [global] 區段。故障節點會缺少整組網域成員設定：
[global]
clustering = yes
ctdb socket = /var/run/ctdb/ctdbd.socket
logging = file:/dev/smbcon
log file = /dev/smbcon
log level = 3
max log size = 0
debug timestamp = no
netbios name = <NETBIOS_NAME>
netbios aliases =
security = user
unix charset = UTF-8
kerberos method = secrets only
ntlm auth = true
idmap config * : backend = autorid
idmap config * : range = 90000001 - 100000000
allow trusted domains = true
directory mask = 777
create mask = 777
...正常節點則是：
[global]
clustering = yes
ctdb socket = /var/run/ctdb/ctdbd.socket
logging = file:/dev/smbcon
log file = /dev/smbcon
log level = 3
max log size = 0
debug timestamp = no
netbios name = <NETBIOS_NAME>
netbios aliases =
realm = <AD_REALM>
workgroup = <WORKGROUP>
server role = member server
security = ADS
unix charset = UTF-8
kerberos method = secrets only
ntlm auth = true
winbind use default domain = false
winbind enum users = true
winbind enum groups = true
winbind cache time = 7200
winbind max domain connections = 10
winbind request timeout = 60
idmap config * : backend = autorid
idmap config * : range = 90000001 - 100000000
idmap config * : sssd_compat = false
idmap config * : unix_nss_info = yes
allow trusted domains = true
directory mask = 777
create mask = 777
...差異集中在四個地方：security 由 ADS 掉成 user；realm、workgroup、server role = member server 三行整組消失；所有 winbind 參數消失；idmap config * : unix_nss_info = yes 消失。只要看到故障節點是 security = user 而正常節點是 security = ADS，大致就可以確定是本問題。
（上述兩份設定的結尾部分在兩台節點上相同且與本問題無關，故以 ... 省略。）
步驟二：檢查 SMB 容器 log
log 會呈現兩類錯誤，分別對應上面兩個症狀。認證階段（對應跳出驗證視窗）：
check_sam_security: Couldn't find user '<user>' in passdb. check_ntlm_password: Authentication for user [<user>] -> [<user>] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1 gensec_spnego_server_negTokenTarg_step: SPNEGO(ntlmssp) login failed: NT_STATUS_NO_SUCH_USER smbd_smb2_request_error_ex: ... status[NT_STATUS_LOGON_FAILURE] || at source3/smbd/smb2_sesssetup.c:147 Server exit (NT_STATUS_CONNECTION_RESET)
名稱解析階段（對應 UID/GID 顯示為數字）：
[nss_winbind] Winbind external command GETPWUID start. Search UID 90298892. Failed with NT_STATUS_NONE_MAPPED. Could not convert sid S-1-5-21-<...>: NT_STATUS_NONE_MAPPED wb_lookupsid_recv failed with NT_STATUS_NONE_MAPPED.
NT_STATUS_NO_SUCH_USER 搭配 NT_STATUS_NONE_MAPPED 同時出現，就是節點已脫離網域成員身分的典型組合。
原因
該節點的 SMB 服務曾經發生斷線。服務在斷線後重新載入時套用到不含網域成員設定的組態，退回本機（security = user）認證模式，因此 Windows 用戶端才會被要求輸入帳密而且必定失敗；同時 winbind 未啟用，無法將檔案上的網域 SID 對應回帳號名稱，ls -l 就只剩下數字 UID/GID。
這是單一節點的服務狀態問題，並非叢集組態或 AD 端設定被更改。
解決方式
登入 UVS Manager，進入 SMB cluster 頁面，勾選發生問題節點的 SMB service，點選 Restart，等待服務狀態恢復正常後，請用戶端重新連線。
驗證
以 \\<節點IP> 連線不再跳出認證視窗，可直接開啟共享資料夾；容器內 smb.conf 已恢復 security = ADS 與 realm / workgroup / winbind 等設定；ls -l 能正確顯示網域帳號名稱。
常見問題
重啟之後設定會不會又跑掉？
不會。正確的組態由叢集端統一下發，SMB 服務重新啟動時會重新取得完整設定，包含網域成員與 winbind 參數。
可以直接從 Cockpit Docker Manager 重啟 SMB 容器嗎？
請優先使用 UVS Manager 的 SMB cluster 頁面執行 Restart。該路徑會依叢集流程處理服務，較為安全一致。
需要先手動修改 smb.conf，或在節點上執行 ceph 相關指令嗎？
都不需要。smb.conf 是由系統產生的，手動編輯容器內的 smb.conf 不會保留，也不建議這麼做。
若問題仍未解決
請聯繫 Ambedded 技術支援並提供：UVS 版本、故障節點 IP、故障節點與正常節點的 smb.conf 對照、SMB 容器 log 片段、用戶端錯誤畫面截圖。