Windows Server 2019 の共有フォルダーに、昨日まで普通につながっていたのに突然アクセスできなくなり、しかも接続ダイアログに「存在しないはずの旧ユーザー名」が毎回出てくる――この手のトラブルは、サーバー側の設定ミスに見えて実はクライアント側の SMB 接続情報（セッション）や保存済み資格情報が原因になっていることが多いです。ここでは、旧ユーザー名が残る典型パターンと、再発まで含めて潰し切る手順を具体的にまとめます。
起きている現象を整理する（旧ユーザー名が出る／正しいユーザーで入れない）
今回の状況は、次のような流れが想定されます。
- Windows Server 2019 上でローカルユーザーを 誤った名前（例：userj） で作成してしまった
- あとからローカルユーザー名を 正しい名前（例：userv） に変更した
- クライアント PC から共有へつなぐと、接続時に 旧ユーザー名（userj）が候補に出る
- 正しいユーザー（userv）で接続しようとすると、「すでに接続がある」系のエラー や認証失敗になる
「他のサーバー共有には接続できる」のに、特定の Windows Server 2019 共有だけおかしい場合、まず疑うべきは そのサーバー宛ての接続がクライアント側に残っている ことです。SMB は「同じサーバー名に対して複数の資格情報で同時接続できない」制約があり、過去の接続が残っていると新しいユーザーでの接続を強く邪魔します。
結論：クライアント側に残った SMB セッション／資格情報をリセットしてから繋ぎ直す
旧ユーザー名が出続ける問題は、次のいずれか（または複合）で起きがちです。
| 症状 | よくある原因 | 優先度の高い対処 |
|---|---|---|
| 接続画面に旧ユーザー名が出る | 資格情報マネージャー／アプリ（ファイル履歴等）が古い資格情報を保持 | 資格情報の削除＋再登録 |
| 正しいユーザーで入ろうとすると「すでに接続がある」 | SMB の既存セッションが残り、別資格情報を拒否（典型例：システム エラー 1219） | net use で接続を全削除 |
| net use * /delete が毎回必要 | ログオン時に自動で再接続されている（永続ドライブ、スクリプト、タスク、GPO） | 自動接続の元を特定して停止 |
以降は、現場で効く順に手順を並べます。まずは「既存接続を切る」→「資格情報を消す」→「自動再接続の原因を止める」の順で進めるのが最短です。
既存の共有接続を全部切断する（最重要）
まずはクライアント PC が保持している SMB 接続（ネットワークドライブ、参照中の共有、残ったセッション）を いったん全て切断 します。これが最優先です。
事前注意：共有上で開いているファイルや、共有を利用中のアプリがあると切断で影響が出ます。可能ならファイル履歴の実行中・バックアップ中でないタイミングで行い、共有ファイルを閉じてから実施してください。
コマンドプロンプト（管理者でなくても可）で次を実行します。
net use * /delete確認を聞かれる場合は Y を選びます。確認を省略したい場合は次でも構いません。
net use * /delete /y「全部は怖い」「対象サーバーだけ切りたい」場合は、まず現在の接続を確認してから、該当だけ削除します。
net usenet use \\SERVERNAME\ShareName /deleteここまでで、「別ユーザーで接続したいのに“すでに接続がある”と言われる」タイプのトラブル（同一サーバーへの複数資格情報禁止）を一気に解消できることが多いです。
すぐに繋ぎ直して挙動を見る
切断後は、明示的にユーザー名を指定して接続します。ローカルユーザーであれば、SERVERNAME\ユーザー名 の形が無難です（ドメイン環境なら DOMAIN\ユーザー名）。
net use \\SERVERNAME\ShareName /user:SERVERNAME\userv ** によりパスワード入力を促されます。ここで正しいユーザー（userv）で通るなら、原因はほぼクライアント側に残っていた接続情報です。
資格情報マネージャーの「保存済み資格情報」を削除する
旧ユーザー名が接続候補に出たり、毎回勝手に旧ユーザーで接続しに行ったりする場合、Windows の 資格情報マネージャー に古い情報が残っている可能性が高いです。特に「ファイル履歴の保存先がネットワーク共有」の構成では、ここが原因になりがちです。
GUI で削除する（確実で分かりやすい）
- コントロール パネル → ユーザー アカウント → 資格情報マネージャー
- Windows 資格情報 を開く
- 対象のサーバー名（例：
SERVERNAME、\\SERVERNAME、SERVERNAME.domain.local、IP アドレスなど）に関連する項目を探す - 旧ユーザー名（userj）で保存されているもの、または該当サーバー宛のものを削除
ポイント：同じサーバーでも、アクセスの仕方が違うと別の資格情報として保存されます。例えば次のように「別物」として扱われがちです。
\\SERVERNAME\Share\\SERVERNAME.domain.local\Share\\192.168.1.10\Share
過去に IP でつないだ、別名（エイリアス）でつないだ、NAS 的に扱っていた、などがあると、見落としやすいので注意してください。
コマンドで削除する（リモート作業・手順書向き）
保存済み資格情報は cmdkey で確認・削除できます。
cmdkey /list一覧に該当サーバーの項目があれば、ターゲット名を指定して削除します（表示された名前をそのまま使うのが安全です）。
cmdkey /delete:SERVERNAME環境によっては TERMSRV/ など別形式で出る場合があります。表示されたターゲットを指定してください。
ネットワークドライブの「永続化（ログオン時に再接続）」を解除する
net use * /delete でその場は直るのに、再起動や再ログオンで旧ユーザー名が復活する場合、Windows がログオン時に「自動でネットワークドライブを再接続」していることがあります。
| チェック箇所 | よくある見え方 | 対処 |
|---|---|---|
| エクスプローラーのネットワークドライブ | ドライブ文字（Z: など）で共有が割り当てられている | 「ネットワークドライブの切断」を実行し、再作成時は「ログオン時に再接続」を慎重に |
| net use の状態 | 永続: はい と出ることがある | 一度削除し、必要なら正しいユーザーで作り直す |
| ファイル履歴（File History） | バックアップ先として共有が登録されている | ファイル履歴の保存先設定をいったん解除→再設定 |
特に「ファイル履歴」の場合、バックアップ先にネットワーク共有を指定すると、PC は定期的に共有へアクセスします。このとき古い資格情報が残っていると、ユーザーが意識していなくても旧ユーザーでアクセスし続け、接続候補として旧ユーザー名がしつこく表示される原因になります。
ファイル履歴を使っている場合の再設定のコツ
- コントロール パネル → ファイル履歴 で、いったん「停止」または保存先を解除する
- 資格情報マネージャーから該当サーバー宛の資格情報を削除する
- 改めてネットワーク場所を選び、正しいユーザー（SERVERNAME\userv など）で認証する
「止める→資格情報削除→設定し直す」をセットで行うと、旧ユーザー名が復活しにくくなります。
ログオン時に“勝手に”古いユーザーで接続している原因を止める
再発する場合に最も重要なのがここです。つまり、どこかに「古い userj で共有へ接続する処理」が残っていて、ログオンのたびに自動実行されている状態です。よくある原因を洗い出します。
ドメイン環境で多い原因（GPO／ログオンスクリプト）
Active Directory 環境の場合、以下が典型的な温床です。
- ログオンスクリプト（バッチや PowerShell）で
net useが実行されている - グループポリシーの「ドライブ マップ（GPP）」で共有が割り当てられている
- 古いサーバー名・古いユーザー名を埋め込んだままのスクリプトが配布されている
ログオンスクリプトは、運用によって置き場所が違いますが、定番として次が候補になります。
- Netlogon 共有（例：
\\ドメイン名\netlogon） - SYSVOL（例：
\\ドメイン名\sysvol配下の scripts）
スクリプト内に次のような記述があると、旧ユーザー名が復活し続けます。
net use Z: \\SERVERNAME\ShareName /user:SERVERNAME\userj ********この場合は、userv に修正するか、できれば資格情報を平文で埋め込む運用は避け、グループ・権限設計や GPP の項目で安全に配布する方針に寄せるのが再発防止として強いです。
ドメインでない環境で多い原因（スタートアップ／タスク）
ワークグループ環境や小規模運用でも、次が原因になることがあります。
- スタートアップに登録されたバッチ（ログオン時にドライブ割り当て）
- タスク スケジューラで、定期的に共有へアクセスするタスクが動いている
- バックアップツールや同期ツールが、古い資格情報を内部に保存している
「意識していないのに勝手につながりに行く」場合は、タスク スケジューラを開いて、共有パス（\\SERVERNAME\ShareName）や net use をキーワードに確認すると見つかることが多いです。
よく出るエラーと意味（切り分けが早くなる）
エラー文は環境により多少異なりますが、代表例を意味とセットで押さえると原因特定が早くなります。
| 表示されがちな内容 | 意味（起きていること） | まず試すこと |
|---|---|---|
| 同じサーバーに別のユーザーで接続できない／既に接続がある（例：システム エラー 1219） | 同一サーバー宛の SMB セッションが既にあり、別資格情報が拒否されている | net use * /delete → 資格情報削除 |
| アクセスが拒否されました | 認証はできたが、共有権限または NTFS 権限が不足 | 共有アクセス権／フォルダー権限の見直し |
| ネットワーク パスが見つかりません | 名前解決・経路・ファイアウォール・共有名ミスなどで到達できない | ping、名前の統一、FW、SMB 有効化確認 |
| 資格情報が正しくありません／ユーザー名またはパスワードが正しくありません | 古いユーザー名が送られている、またはパスワード不一致 | 資格情報マネージャー削除→明示指定で再接続 |
サーバー側も一応チェックする（ユーザー名変更の落とし穴）
今回の主因はクライアント側の残骸であることが多い一方、サーバー側も最低限だけ確認しておくと、二度手間を防げます。
ローカルユーザーを「名前変更」した場合の注意点
Windows のローカルユーザーは、表示名を変更しても内部的には SID（セキュリティ ID）で管理されます。そのため、共有フォルダーのアクセス権（ACL）上は同じ実体のまま動くこともありますが、運用的には次のような混乱が起きがちです。
- ACL の表示がすぐに新しい名前に追随せず、旧名のまま見えることがある
- クライアント側は「ユーザー名文字列」で資格情報を保持するため、旧名が残りやすい
- 誤って旧名の別ユーザーを新規作成してしまうと、権限が分裂してさらに混乱する
共有権限と NTFS 権限の基本形を整える
共有トラブルを長期的に減らすなら、共有権限と NTFS 権限を「ユーザー直指定」ではなく「グループで付与」に寄せるのが効果的です。例えば次の考え方です。
- サーバーにローカルグループ（例：
FileHistoryUsers）を作る - 共有・NTFS 権限はそのグループに付与する
- 実ユーザー（userv など）はグループに所属させる
こうすると、ユーザー名の変更や入れ替えが起きても、共有側の権限を触る回数が減り、クライアント側の「旧名が残る」事故も間接的に減ります。
PowerShell で共有設定を確認する例
管理者が確認する場合は、PowerShell で共有とアクセス権を素早く確認できます。
Get-SmbShare
Get-SmbShareAccess -Name "ShareName"「共有アクセス権はあるのに入れない」場合は、NTFS 権限（フォルダーのセキュリティ）側で止まっていることも多いので、共有と NTFS の両方をセットで見直してください。
それでも直らないときの追加手当（“残りカス”を消す）
基本手順（net use 削除＋資格情報削除＋自動接続停止）で改善しない場合、クライアントの状態が頑固に残っていることがあります。次の手当を上から順に試します。
Workstation サービスを再起動して SMB 状態をリセットする
SMB クライアント機能（Workstation サービス）を再起動すると、残っている接続がさらにクリアされることがあります。ただし、ネットワーク共有を利用中のアプリがあると影響が出るため、実施タイミングに注意してください。
net stop workstation
net start workstationドメイン環境なら Kerberos チケットも疑う
ドメインユーザーでアクセスしている環境では、資格情報の見え方が Kerberos チケットに引っ張られることがあります。切り分けとしては有効です。
klistklist purgeただし今回のように「サーバーのローカルユーザー」で認証しているケースでは、主戦場はあくまで SMB 接続と保存資格情報です。Kerberos は補助的な切り分けとして考えるのが現実的です。
接続先の表記ゆれを統一する（地味に効く）
資格情報が「サーバー名」「FQDN」「IP」で別管理される都合上、運用で表記が揺れると旧情報が残りやすくなります。ファイル履歴の保存先、ショートカット、ドライブ割り当て、手動アクセスのすべてで、できるだけ次のどれかに統一すると安定します。
- サーバー名（例：
\\SERVERNAME\Share）に統一 - FQDN（例：
\\SERVERNAME.domain.local\Share）に統一
IP アドレス接続は短期の切り分けには便利ですが、資格情報が分裂しやすいので常用は避けた方がトラブルが減ります。
再発防止：ユーザー名ミスを「事故」で終わらせない運用ポイント
今回のような「ユーザー名を誤って作成→後から修正」は、どの現場でも起こり得ます。再発を減らすなら、技術的な対処に加えて運用面の工夫が効きます。
| 再発しやすい原因 | おすすめの予防策 | 期待できる効果 |
|---|---|---|
| ユーザーを直指定で権限付与している | 共有・NTFS はグループに付与し、ユーザーはグループ所属 | ユーザー変更時の影響範囲が小さくなる |
| ドライブ割り当てがスクリプトに散在 | GPO/GPP など配布元を一本化して管理する | 古い userj を根絶しやすい |
| サーバー名の表記が揺れている | アクセスの表記（SERVER/FQDN）を統一し、手順書も統一 | 資格情報が分裂しにくい |
| 平文パスワードで net use している | 可能なら仕組みを見直し、認証情報の扱いを改善 | セキュリティと運用の両面で事故が減る |
最終手段としての「OS 再インストール／プロファイル作り直し」
まれに、クライアントの状態が複雑に絡み合っていて、手順を踏んでも旧ユーザー名の挙動が消えないことがあります。スレッドや現場でも「Windows の再インストールで消えた」という結末が出ることはありますが、再インストールはコストが大きいので、通常は次の順で最終判断するのが現実的です。
- 別の PC では問題なく接続できるか（問題がクライアント限定かを確定）
- 当該 PC だけで、net use 全削除＋資格情報削除＋自動接続停止 をやり切ったか
- それでも改善しない場合に限り、ユーザープロファイルの作り直しや OS 再セットアップを検討
まとめ：まず net use、次に資格情報、最後に自動接続の元を潰す
Windows Server 2019 の共有に突然つながらなくなり、存在しない旧ユーザー名が毎回出る問題は、サーバー側の「ユーザー名変更」がきっかけでも、原因の本体はクライアント側に残った SMB 接続情報／保存資格情報であることが多いです。まず net use で既存接続を切る、次に 資格情報マネージャーで古い資格情報を消す、そして再発するなら ログオン時の自動接続（スクリプトや永続ドライブ）を止める――この順で対応すると、最短で安定に戻せます。
コメント