回答:
Windowsでは、あなたがすることができない UNCパスで資格情報を置きます。を使用net useしてrunas /netonly、またはWindowsから要求されたときにそれらを提供する必要があります。（プログラミングスキルをお持ちの場合CredWrite()は、Windowsの[ パスワードを保存] ボックスをチェックするのと同等の、「ドメイン資格情報」としてSMBパスワードを保存できます。）
Linuxでは、プログラムに依存します。
GNOMEのGvfsはuser@host構文を受け入れますが、パスワードを完全に無視するようです。（ただし、事前にGNOME Keyringに保存できます。）
smbclientWindowsと同じUNC構文を使用します。ただし、--authentication-file資格情報を読み取ることができるオプションがあります。
上記の両方のプログラムはlibsmbclientを使用しており、パスワードの代わりにKerberos認証を使用できます：run kinit user@YOUR.DOMAINおよびuse smbclient -k //host/share。これは、パスワード認証よりも安全です。
URIにパスワードを入力することは非推奨であり、どこでもサポートされていることに頼るべきではないことに注意してください。
ファイルアクセスを行う前に、まず認証のためにユーザー名とパスワードをサーバーに渡す必要があるため、SMB接続を処理するコードは、URLからユーザー名とパスワードを解析し、追加できる必要があります。そのコードがこの形式をサポートしているかどうかを確認する必要があります。
そうでない場合は、SAMBAを介してそのSMB共有をマウントし、その「ローカル」パスを使用するようにプログラムに指示することができます。マウントをfstabSAMBAパスワードファイルに入れて使用し、ユーザー資格情報を提供できます。通常のユーザーが読み取れないように、パスワードファイルに正しい権限を設定してください。
設定ファイルにパスワードを平文で保存するのは悪い習慣なので、プログラムがURLでパスワードを処理できる場合でも、マウントされた共有方法を考慮する必要があります。
fstab「クリアテキスト設定ファイル」ではありませんか？
非ドメインPCは、サブスクライブまたは直接参加しないDFSを実際に気にするべきではありません。共有パス（つまり、サーバー/共有名）を表示するだけです。共有名は、ホストファイルサーバーのパスに関するすべての考慮事項を削除します。
正直なところ、共有にログオンするには、UNC URIよりも安全な方法があります。UNCとURIは、それ自体がクリアテキスト通信プロトコルです。
それが許容できるセキュリティである場合...なぜユーザーまたはパスワードなしでオープンな共有があるだけではありませんか？
最も簡単な即時解決策は、サービス資格情報に共有へのログオンへの直接アクセスを与えることです（たとえば、一致するユーザー/パスワード）。長期的にはそれほど明確な一致ではないため、状況が変化した場合はいつでもアクセス許可を更新することを忘れないようにします。また、MSがセキュリティが資格情報を再度渡す方法を変更し、物事を壊す可能性のある領域でもあります。
長期的に最も簡単なことは、おそらくローカルドライブ文字をネットワーク共有に永続的にマップすることです。マップされたドライブを、サービス（および適切な管理者など）のみのアクセス許可で保護し、さらに共有名を先頭の＆で非表示にすることができます。
しかし、DFSはよりエレガントなソリューションへの手がかりを提供します。Linuxでは、ネットワーク共有を最初にマウントする必要があります...通常は、DFSと非常によく似た方法でルートファイルシステムのディレクトリとしてマウントされます。Linuxのmountコマンドでは、ユーザー名とパスワードの資格情報ファイルを指定できるため、コマンドラインスクリプトやfstab（ファイルシステムテーブル）よりも更新が簡単で安全です。WindowsコマンドシェルとDFSが同じことを（かなり前に）できると確信しています。スクリプトでハードコードされてクリアテキストUNCとして送信されるのではなく、SMBおよびログオンサービスによって渡される保存された資格情報を使用して、マウントされたネットワーク共有を組み込むのは、ターゲットPC専用の別のDFSシステムです。
また、その非ドメインPCが長期にわたって非ドメインPCのままかどうかを検討してください。* NIX RealmsのKerberosログオンサーバーは、Windows ADドメインにリンクできます。おそらく、数人以上が関与する深刻な長期プロジェクトに対して何をしたいのでしょう。一方、ほとんどのホームネットワークの状況ではおそらく過剰になります。ただし、趣味の自己挑戦以外の正当な理由でDFSを使用している場合は、おそらく最善です。
Mattによる資格情報ストレージの回答は、最新のWindows PCにとって最もエレガントです。明記されていませんが、使用される資格情報ストレージはサービスアカウント用である必要があります。これは、サービスの可用性を確保するためと、その共有にアクセスしたくない他のユーザーができないようにするためです（たとえば、間違ったアカウントで誤って追加された資格情報をクリーンアップすることを忘れないでください）。
しかし、レガシーWindowsまたはLinuxの場合、少し広くする必要があるかもしれません。
非ドメインPCは、サブスクライブまたは直接参加しないDFSを実際に気にするべきではありません。共有パス（つまり、サーバー/共有名）を表示するだけです。共有名は、ホストファイルサーバーのパスに関するすべての考慮事項を削除します。
正直なところ、共有にログオンするには、UNC URIよりも安全な方法があります。UNCとURIは、それ自体がクリアテキスト通信プロトコルです。
それが許容できるセキュリティである場合...なぜユーザーまたはパスワードなしでオープンな共有があるだけではありませんか？
最も簡単な即時解決策は、サービス資格情報に共有へのログオンへの直接アクセスを与えることです（たとえば、一致するユーザー/パスワード）。長期的にはそれほど明確な一致ではないため、状況が変化した場合はいつでもアクセス許可を更新することを忘れないようにします。また、MSがセキュリティが資格情報を再度渡す方法を変更し、物事を壊す可能性のある領域でもあります。
長期的に最も簡単なことは、おそらくローカルドライブ文字をネットワーク共有に永続的にマップすることです。マップされたドライブを、サービス（および適切な管理者など）のみのアクセス許可で保護し、さらに共有名を先頭の＆で非表示にすることができます。
しかし、DFSはよりエレガントなソリューションへの手がかりを提供します。Linuxでは、ネットワーク共有を最初にマウントする必要があります...通常は、DFSと非常によく似た方法でルートファイルシステムのディレクトリとしてマウントされます。Linuxのmountコマンドでは、ユーザー名とパスワードの資格情報ファイルを指定できるため、コマンドラインスクリプトやfstab（ファイルシステムテーブル）よりも更新が簡単で安全です。WindowsコマンドシェルとDFSが同じことを（かなり前に）できると確信しています。スクリプトでハードコードされてクリアテキストUNCとして送信されるのではなく、SMBおよびログオンサービスによって渡される保存された資格情報を使用して、マウントされたネットワーク共有を組み込むのは、ターゲットPC専用の別のDFSシステムです。
また、その非ドメインPCが長期にわたって非ドメインPCのままかどうかを検討してください。* NIX RealmsのKerberosログオンサーバーは、Windows ADドメインにリンクできます。おそらく、数人以上が関与する深刻な長期プロジェクトに対して何をしたいのでしょう。一方、ほとんどのホームネットワークの状況ではおそらく過剰になります。ただし、趣味の自己挑戦以外の正当な理由でDFSを使用している場合は、おそらく最善です。