4 Sambaの管理
この章では、Oracle Linux 8でのSambaの管理について説明します。
Oracle Linuxでのローカル・ファイル・システムの管理の詳細は、『Oracle Linux 8 ローカル・ファイル・システムの管理』を参照してください。
Sambaについて
SambaはServer Message Block (SMB)プロトコルのオープン・ソース実装です。Oracle Linuxはこれを使用して、Windows、その他のLinuxフレーバ、macOSなどの様々なOSを実行しているクライアントと相互運用できます。
Linuxサーバーのファイルと印刷の両方のリソースを共有するようにSambaを構成できます。たとえば、Sambaを使用してLinuxホストを構成し、ネットワーク上のWindowsユーザーが次の構文を使用してアクセスできるファイル共有の場所を作成できます。
\\samba_server\share_name
上記の例で注目すべき点は以下のとおりです。
- samba_serverは、Sambaサービスを実行しているシステムのIPアドレスまたはネットワークで解決可能なホスト名です。
- share_nameは、Samba構成ファイル
/etc/samba/smb.conf
で定義されているリソースの名前です。
ノート:
ロケーション・パスの形式は、クライアントのオペレーティング・システムによって異なります。たとえば、macOSなどのUNIXおよびLinuxベースのOSの場合、パスの形式はsmb://samba_server/share_name
のようになります。
Sambaには、WindowsワークグループおよびActive Directory (AD)ドメインと統合する機能が付属しています。
Sambaには、Microsoft WindowsがWindowsクライアントにファイル・サービスと印刷サービスをプロビジョニングするために使用する、分散コンピューティング環境リモート・プロシージャ・コール(DCE RPC)プロトコルが実装されています。
SambaはTCP/IPプロトコル経由でNetBIOSを使用するため、NetBIOS APIに依存するコンピュータ・アプリケーションがTCP/IPネットワーク上で動作できます。
Sambaサービスについて
Sambaサーバーは、次の複数の重要なサービスからなります。
smb
サービス-
smb
サービスはSMBプロトコルを使用して、ファイルの共有と印刷サービスを有効にします。このサービスは、リソースのロックと接続ユーザーの認証も行います。smb systemd
サービスはsmbd
デーモンを起動および停止します。次にコマンドの例を示します。sudo systemctl start smb.service
smbd
サービスを使用するには、システムにsamba
パッケージをインストールする必要があります。 nmb
サービス-
nmb
(NetBIOS Message Block)サービスは、NetBIOS over IPv4プロトコルを使用することでホスト名とIP解決を提供します。nmb
サービスを使用すると、SMBネットワークを参照して、ドメイン、ワークグループ、ホスト、ファイル共有およびプリンタを見つけることもできます。nmb systemd
サービスはnmbd
デーモンを起動および停止します。次にコマンドの例を示します。sudo systemctl start nmb.service
nmbd
サービスを使用するには、システムにsamba
パッケージをインストールする必要があります。 winbind
サービス-
winbind
サービスは、ADユーザーおよびグループを解決するためのネーム・サービス・スイッチ(NSS)デーモンです。ADユーザーは、このデーモンによってSambaサーバー上でホストされているサービスに安全にアクセスできます。winbind systemd
サービスはwinbindd
デーモンを起動および停止します。次にコマンドの例を示します。sudo systemctl start winbind.service
winbindd
サービスを使用するにはsamba-winbind
パッケージをインストールします。
ノート:
Sambaをドメイン・メンバーとして設定する場合は、winbind
サービスを開始してからsmb
サービスを開始する必要があります。そうしないと、ドメイン・ユーザーとグループはローカル・システムで使用できません。
Samba構成ファイルについて
Sambaは/etc/samba/smb.conf
ファイルを使用して、Samba構成を管理します。
smb.conf
ファイル構造の概要
smb.conf
ファイルは複数のセクションで構成され、特定のSamba構成に必要なサービスをサポートするように構成できます。次に、smb.conf
ファイルからの抽出例を示します。
#========== Global Settings =======
[global]
security = ADS
realm = EXAMPLE.REALM
password server = krbsvr.example.com
.
.
.
load printers = yes
printing = cups
printcap name = cups
#========== Share Definitions =========
[homes]
comment = User home directories
path = /data/pchome/%S
valid users = %S, WWW.EXAMPLE.COM\%S
browsable = no
read only = no
guest ok = no
[printers]
comment = All Printers
path = /var/spool/samba
printable = yes
[test_share]
comment = Shared /usr/local/test_share directory created for tests
path = /usr/local/test_share
valid users = @examplegroup
browsable = yes
read only = no
次のリストは、前述の構成例のセクションについて説明しています。
-
[global]
-
このセクションには、Sambaサーバーのグローバル設定が含まれています。
前述の例で、
security
パラメータ値ADS
は、サーバーがネイティブ・モードで実行されているADドメインのメンバーであることを意味します。このシナリオでは、Sambaは、ローカル・サービスにアクセスするクライアントを認証するために、Kerberosサーバーで発行されるチケットを利用します。 -
[homes]
-
[homes]
セクションでは、Sambaサーバーにログオンするユーザーの個人共有を提供します。この例では、各ユーザーのホーム・ディレクトリの場所はpath = /data/pchome/%S
行で設定されます(%S
マクロはユーザー名で置換されます)。browsable = no
およびread only = no
の設定によって、他のユーザーがホーム・ディレクトリを参照するのを防ぐ一方、有効なユーザーには完全なアクセスを付与します。重要:
セキュリティなどの設定に注意してください。特別なセクションである
[global]
、[homes]
および[printers]
では特に注意が必要です。たとえば、
[homes]
セクションでゲスト・アクセスが指定されている場合は、すべてのホーム・ディレクトリがパスワードなしですべてのクライアントに表示されます。root
などのユーザーや管理権限がある他のユーザーについては、invalid users
パラメータを使用することを検討できます。 -
[printers]
-
印刷サービスのサポートを指定します。
path
パラメータは、印刷ジョブをローカルのPrint Spoolerに発行する前に、Windowsクライアントから印刷ジョブを受け取るスプール・ディレクトリの場所を指定します。Sambaは、サーバー上のローカルに構成されたすべてのプリンタを通知します。
-
[test_share]
-
test_shareという名前の共有を指定します。これにより、グループexamplegroupに属するユーザーに
/usr/local/test_share
ディレクトリに対する参照および書込み権限を付与します。ノート:
read only = no
構成エントリは、書込み可能な共有としてSambaがディレクトリを共有するために不可欠です。
詳細は、/etc/samba/smb.conf.example
、smb.conf(5)
のマニュアル・ページおよびhttps://wiki.samba.org/index.php/User_Documentationを参照してください
testparm
プログラムを使用したSamba構成ファイルの内容の検証
構成の変更後に、testparm
プログラムを使用してSamba構成ファイルを検証します。testparm
プログラムは、無効なパラメータおよび値と、不正なIDマッピングなどの不正な設定を検出します。
ノート:
testparm
では、構成ファイルの内部的な正確性のみがチェックされます。testparm
コマンドでは、構成されたサービスが使用できるか、期待どおりに動作するかをテストできません。
次の例は、コマンドを使用して作業中のファイルのコピーをテストする方法を示しています:
sudo testparm /etc/samba/smb.conf.my_copy
Load smb config files from /etc/samba/smb.conf.my_copy
Loaded services file OK.
...
コピーではなくデフォルトのSamba構成ファイルをテストする場合は、ファイルをパラメータとして指定する必要はありません。testparmは、次のように単純に実行できます。
sudo testparm
testparm
コマンドにより構成ファイル内のエラーや構成ミスが報告された場合は、問題を修正してコマンドを再発行する必要があります。
詳細は、testparm(1)
マニュアル・ページを参照してください。
Samba構成を編集する際のベスト・プラクティス
Sambaサービスは、次のように構成をリロードします。
- ほとんどの構成値は、3分ごとに自動的にリロードされます。
- たとえば、
smbcontrol all reload-config
コマンドを使用して、リロードを手動でリクエストすることもできます。
ノート:
security
などの一部のパラメータは、有効にするためにsmb
サービスを再起動する必要があります。
構成値を頻繁にリロードしても、/etc/samba/smb.conf
に加えようとしている変更を検証する時間は多くありません。そのため、最初に構成ファイルのコピーで変更をテストすることをお薦めします。次のステップでは、この方法について説明します。
-
samba構成ファイルのコピーを作成します。
sudo cp /etc/samba/smb.conf /etc/samba/samba.conf.mycopy
-
vi
などの任意のエディタで開いた後、ファイルのコピーを編集します。sudo vi /etc/samba/samba.conf.mycopy
-
testparm
を使用して変更を検証します:sudo testparm /etc/samba/smb.conf.my_copy
-
検証したコピーで元のファイルを上書きします。
sudo mv /etc/samba/samba.conf.my_copy /etc/samba/smb.conf
-
smbcontrol all reload-config
コマンドを使用して構成をリロードします。sudo smbcontrol all reload-config
Sambaサーバーの役割について
次の項では、Sambaサーバーに対して構成できる様々な役割の概要を示します。
スタンドアロン
サーバーがドメインの一部である必要がないピアツーピアのワークグループなど、小規模なネットワークでは、Sambaサーバーの役割をスタンドアロン・サーバーとして構成できます。
スタンドアロン・サーバーの共有に対して認証されたアクセスをWindowsユーザーに提供するには、Sambaサーバーに次のアカウントを作成します。
-
ローカルLinuxアカウント
ローカル・ファイル・システムのオブジェクトへのアクセスを検証するには、ローカルLinuxアカウントが必要です。
-
Sambaアカウント
スタンドアロン構成では、Sambaは、ドメイン・コントローラではなくローカル・データベースに対してユーザーを認証します。このようなアカウントを作成するには、Sambaの
smbpasswd
コマンドを使用します。
認証されたアクセスに加えて、ユーザーが一部のサービスに認証なしで接続できるように、ゲスト・アクセスも有効にできます。
Active Directoryドメインのドメイン・メンバー
ノート:
Oracle Linuxでは、ADドメイン・コントローラ(DC)としてのSambaの実行はサポートされていませんADドメイン・ネットワークでSamba共有を設定する必要がある場合は、Sambaサーバーの役割をActive Directory (AD)ドメインのドメイン・メンバーとして構成します。
Samba ADドメイン・メンバーの設定には、次の作業が必要です。
-
Kerberos
のインストールSambaサーバーは、
Kerberos
を使用して、ドメイン・コントローラに対してWindows ADユーザーを認証します。 -
winbind
サービスのインストールwinbind
サービスは、Windows ADユーザーおよびグループに関する情報をLinux OSに提供します。したがって、SambaサーバーがADメンバーとして構成されている場合は、Samba共有に対する認証されたアクセスのために、ローカルのLinuxユーザーとグループを手動で作成する必要はありません。 -
IDマッピング・バックエンドの構成
Sambaには、バックエンドと呼ばれる様々なIDマッピング方法が用意されており、各Linux
GID
およびUID
を対応するWindowsSID
にマップするように構成できます。使用するバックエンドを選択し、/etc/samba/smb.conf
ファイルで構成します。「アクティブ・ドメイン・メンバー設定でのIDマッピング・バックエンド」を参照してください
アクティブ・ドメイン・メンバー設定でのIDマッピング・バックエンド
LinuxおよびWindowsでは、それぞれ異なるIDシステムを使用してグループとユーザーが識別されます。
Linuxではグループおよびユーザーに一意のGIDおよびUID番号が割り当てられますが、Windowsでは、各ユーザーおよびグループに対してセキュリティ識別子の値(SID)が使用されます。
winbindサービスでは、各Linux GIDおよびUIDから対応するWindows SIDへの必要なマッピングが保持されます。一方、ユーザーには、このマッピングに使用可能なマッピング方法(Sambaで呼び出されるバックエンド)を指定する責任があります。
Samba構成ファイルでのIDマッピングの概要
マッピングは、Samba構成ファイル/etc/samba/smb.conf
の[global]
セクションで構成します。
次のsmb.conf
ファイルからの抽出の例を考えてみます:
#========== Global Settings =======
[global]
security = ADS
.
.
.
#..........................................
# Using tdb backend for default* domain.
# UID/GID range 1000000-2000000
#..........................................
idmap config * : backend = tdb
idmap config * : range = 1000000-2000000
#..........................................
# Using rid backend to map EXAMPLE.COM users
# UID/GID range 10000-49999
#..........................................
idmap config EXAMPLE.COM : backend = rid
idmap config EXAMPLE.COM: range = 10000-49999
#..........................................
# Using rid backend to map EXAMPLE.NET users
# UID/GID range 50000-99999
#..........................................
idmap config EXAMPLE.NET : backend = rid
idmap config EXAMPLE.NET : range = 50000 -99999
前述の抽出例では、次の構成が示されています。
-
SambaサーバーはEXAMPLE.COM ADドメインのメンバーであり、
rid
バックエンドを使用して、そのドメインに属するSID
をマップします。バックエンドは、rid
メソッドによりファイルに指定されている範囲内(10000-49999
)のUID
およびGID
に変換されるSID
に対して権限があります。 -
Sambaサーバーは、信頼できるADドメインEXAMPLE.NETへの共有アクセスも提供します。また、信頼できるドメインは、
rid
バックエンドを使用するように構成されます。EXAMPLE.NETの範囲は50000-99999
です。 -
デフォルトの
*
ドメインでは、バックエンドtdb
が使用されます。tdb
の範囲は、1000000-2000000
として指定されます
警告:
- ID範囲は重複できません。
- 1つのドメインに割当可能な範囲は1つのみです。
- 範囲を設定して、Sambaがその範囲の使用を開始した後は、範囲の上限のみを増加できます。範囲にその他の変更を加えると、新しいIDが割り当てられるため、ファイルの所有権データが失われる可能性があります。
次の項では、様々なバックエンドを使用したドメインのIDマッピングの構成について概要を説明します。
詳細は、/etc/samba/smb.conf.example
およびsmb.conf(5)
のマニュアル・ページを参照してください。https://wiki.samba.org/index.php/User_Documentationおよびアップストリームのドキュメントも参照してください。
IDマッピング構成を必要とするドメイン
次のものに対してIDマッピングを構成する必要があります。
-
SambaサーバーがメンバーであるADドメイン。
-
Sambaサーバーにアクセスする可能性がある、信頼できる各ADドメイン。
-
*
デフォルト・ドメイン。デフォルト・ドメインには、
BUILTIN\Administrators
などのSamba組込みアカウントおよびグループが含まれています。
使用可能なバックエンド
表4-1 最も一般的に使用されるIDマッピングのバックエンド
バックエンド | バックエンドを使用できるドメイン |
---|---|
tdb |
* デフォルト・ドメインでのみ使用します。
|
ad |
ADドメインで使用します。 |
rid |
ADドメインで使用します。 |
autorid |
ADおよび* デフォルト・ドメインの両方で使用できます。
|
次の項では、前述の表に示されているバックエンドの概要について説明します。
tdb
マッピング・バックエンド
tdb
バックエンドは、winbindd
がセキュリティ識別子(SID
)、UID
およびGID
のマッピング表を格納する際に使用するデフォルトのバックエンドです。
tdb
バックエンドは、*
デフォルト・ドメインにのみ使用する必要があります。
デフォルト・ドメインには、BUILTIN\Administrators
などのSamba組込みアカウントおよびグループが含まれています。
tdb
バックエンドは、新しいマッピングを作成するために、新しいユーザーおよびグループのIDを割り当てるのに必要な書込み可能なバックエンドです。
IDマッピングはサーバーに対してローカルです。
ad
マッピング・バックエンド
ad
バックエンドを使用すると、winbind
はRFC2307
スキーマ拡張を使用するADサーバーからIDマッピングを読み取ることができます。
たとえば、ad
バックエンドを使用する場合、ADアカウントのuidNumber
属性に値を入力して、ユーザーのLinux UID
番号を設定します。
Windows ADサーバーで設定するいくつかの属性が、次の表の最初の列にリストされており、各属性でマップされる対応するLinux値がそれぞれの2番目の列にリストされています:
表4-2 AD
マッピング使用時のADサーバーの属性の表
Windows ADサーバーの属性セット | AD属性でマップされる対応するLinux値 |
---|---|
uidNumber
|
UID
|
gidNumber
|
GID
|
sAMAccountName
|
ユーザー名またはグループ名 |
ノート:
- 前述の表のリストは概要として提供しています。その他の属性については、アップストリームのドキュメントを参照してください。
- マッピングIDは、
/etc/samba/smb.conf
で構成された範囲内である必要があります。IDが範囲外のオブジェクトは、Sambaサーバーでは使用できません。
ad
には次の利点があります:
-
UID
とGID
は、ad
を使用するすべてのSambaサーバーで一貫しています。 -
ID値はローカル・データベースに格納されないため、ローカル・データの破損やファイル所有権データの損失の可能性が低くなります。
rid
マッピング・バックエンド
rid
バックエンドは、Windows SID
のRID
(相対識別子)部分を使用してWindowsグループおよびユーザーをUID
およびGID
にマップするアルゴリズム・マッピング・スキームです。
rid
には次の利点があります:
-
マップされたIDが
/etc/samba/smb.conf
で指定されたドメインのrid
範囲内にある場合は、すべてのドメイン・ユーザー・アカウントおよびグループがドメイン・メンバーで自動的に使用可能になります。 -
ドメイン・ユーザーおよびグループに対して属性を設定する必要がありません。
autorid
マッピング・バックエンド
autorid
バックエンドは、rid
IDマッピング・バックエンドと同様に機能しますが、autorid
の利点の1つは、異なるドメインのIDを自動的に割当てできることです。autorid
バックエンドは、次に対して使用できます:
-
*
デフォルト・ドメインおよび追加のドメイン。追加のドメインごとにIDマッピング構成を作成する必要はありません。 -
特定のドメインに対してのみ。
Sambaスタンドアロン・サーバーの構成
次の手順は、Sambaスタンドアロン・サーバーを構成するための1つの方法を示しています。
-
samba
パッケージをインストールします。sudo dnf install samba
-
/etc/samba/smb.conf
ファイルを編集し、様々なセクションを特定の構成に必要なサービスをサポートするように構成します。ノート:
Samba構成ファイルを編集する方法の詳細は、「Samba構成を編集する際のベスト・プラクティス」を参照してください。次のケースについて検討します。
#========== Global Settings ========= [global] workgroup = EXAMPLE_WORKGROUP netbios name = Server_Netbios_Name security = user role = standalone server passdb backend = tdbsam log file = /var/log/samba/%m log level = 1 #========== File Share ========= [shareexample] path = /srv/samba/shareexample/ read only = no
前述の例では、ワークグループEXAMPLE_WORKGROUPでServer_Netbios_Nameという名前のスタンドアロン・サーバーを次の設定で構成しています。
-
role = standalone server
設定するサーバーのタイプ。
-
passdb backend = tdbsam
Sambaがユーザー・アカウントを
/var/lib/samba/private/passdb.tdb
データベースに格納するデフォルト設定。 -
log level = 1
ロギングの最低レベル。
-
log file = /var/log/samba/%m
ログ・ファイルのパス。
%m
変数は、クライアント・マシンのNetBIOS名で置換されます。 -
[shareexample]
共有の名前はshareexampleとして構成されます。ユーザーが共有にアクセスするために使用する名前です。
-
read only = no
Sambaが書き込み可能な共有としてディレクトリを共有します。
-
-
Samba構成ファイルを検証します。
sudo testparm
-
ホーム・ディレクトリなし(
-M
)およびログイン・シェルなし(-s /sbin/nologin
)で、ローカルLinuxユーザー・アカウントを作成します。sudo useradd -M -s /sbin/nologin exampleUser
-
パスワードを設定してユーザーを有効にします。
sudo passwd exampleUser Changing password for user exampleUser. New password: Retype new password: passwd: all authentication tokens updated successfully.
ノート:
passwd
アカウントで設定されたローカル・パスワードは、Sambaで使用されるものではありません。ただし、アカウントを有効にするにはローカル・パスワードを設定する必要があります(アカウントがローカルで無効になっていると、Sambaによってアクセスが拒否されます)。
-
SambaデータベースにexampleUserアカウントを追加します。
sudo smbpasswd -a exampleUser New SMB password: Retype new SMB password: Added user exampleUser
ノート:
このステップでsmbpasswd
コマンドを使用して設定されたSambaアカウントのパスワードは、Sambaが使用するパスワードです -
Linuxグループを作成します。
sudo groupadd exampleGroup
前のステップで作成したグループexampleGroupにユーザーexampleUserを追加します。
sudo usermod -aG exampleGroup exampleUser
-
/etc/samba/smb.conf
の指定された共有で参照される共有ディレクトリが存在しない場合は、そのディレクトリを作成します:sudo mkdir -p /srv/samba/shareexample/
ノート:
SELinuxをenforcing
モードで実行する場合は、ディレクトリにsamba_share_t
コンテキストを設定して、SELinuxでSambaによる読取り/書込みを許可します。sudo semanage fcontext -a -t samba_share_t "/srv/samba/shareexample(/.*)?" sudo restorecon -Rv /srv/samba/shareexample/
-
共有ディレクトリのグループを、Sambaユーザー用に前のステップで作成したグループに設定します:
sudo chgrp -R exampleGroup /srv/samba/shareexample/
-
共有ディレクトリの権限を設定します。
sudo chmod 2770 /srv/samba/shareexample/
-
必要なポートを開き、
firewall-cmd
ユーティリティを使用してファイアウォール構成をリロードします。sudo firewall-cmd --permanent --add-service=samba sudo firewall-cmd --reload
-
smb
サービスを有効にして開始します。systemctl enable --now smb
ADメンバーとしてのSambaサーバーの構成
次の手順は、SambaサーバーをADメンバーとして構成する1つの方法を示しています。
-
次のパッケージをインストールする必要があります。
-
realmd
realmd
ツールは、Active DirectoryドメインなどのKerberos
レルムに参加するために使用されます。 -
oddjob
およびoddjob-mkhomedir
oddjob
は、クライアント・アプリケーションのかわりにジョブを実行するD-Busサービスです。oddjob-mkhomedir
は、ホーム・ディレクトリを作成および移入するoddjob
ヘルパーです。 -
samba-winbind-clients
、samba-winbind
、samba-common-tools
、samba-winbind-krb5-locator
およびsamba
。次のコマンドを実行して、必要なパッケージをインストールできます。
sudo dnf install realmd \ oddjob-mkhomedir \ oddjob \ samba-winbind-clients \ samba-winbind \ samba-common-tools \ samba-winbind-krb5-locator \ samba
-
-
Samba構成ファイルのバックアップ・コピーを作成します。
sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.copy
-
realm join
コマンドを使用して、ADドメインに参加します。次の例では、ドメインEXAMPLE.COM
に参加することを想定しています:sudo realm join --membership-software=samba \ --client-software=winbind EXAMPLE.COM
次のようにコマンドを実行すると、
realm
によって次の処理が実行されます。-
EXAMPLE.COMドメインのメンバーシップが構成されている
/etc/samba/smb.conf
ファイルを作成します。 -
ユーザーおよびグループの参照用の
winbind
モジュールを/etc/nsswitch.conf
ファイルに追加します。 -
/etc/pam.d/
ディレクトリのPluggable Authentication Module (PAM)構成ファイルを更新します -
winbind
サービスを開始して有効化します。
-
-
構成に必要なIDマッピングを
/etc/samba/smb.conf
ファイルに設定します。IDマッピングの詳細は、「アクティブ・ドメイン・メンバー設定でのIDマッピング・バックエンド」を参照してください
-
/etc/samba/smb.conf
ファイルのエントリが構成要件すべてを満たしていることを確認します。構成ファイルの詳細は、「Samba構成ファイルについて」を参照してください
-
winbind
サービスが実行されていることを確認します。sudo systemctl status winbind
重要:
smb
サービスを開始する前に、winbind
サービスが実行されている必要があります。そうしないと、Sambaはドメイン・ユーザーおよびグループの情報を取得できません。 -
前のステップで
winbind
が実行されていることを確認してから、smb
サービスを開始して有効化します:sudo systemctl enable --now smb
-
次のような検証ステップを実行します。
-
ドメイン・ユーザーの詳細を取得します。次に示している記述は、EXAMPLE.COMドメインのユーザーexampleuserの詳細が取得されていることを前提としています。
sudo getent passwd EXAMPLE.COM\\exampleuser
EXAMPLE.COM\exampleuser:*:10000:10000::/home/exampleuser@EXAMPLE.COM:/bin/bash
-
コマンドをテストして、ドメインの
Domain Users
グループからユーザーを取得します。次に示している記述は、EXAMPLE.COMドメインのDomain Users
グループのユーザーの詳細が取得されていることを前提としています。sudo getent group "EXAMPLE.COM\Domain Users"
EXAMPLE.COM\domain users:x:10000:exampleuser1,exampleuser2
-
ファイルおよびディレクトリのコマンドを使用する際にドメイン・ユーザーおよびグループを使用できることを確認します。たとえば、/srv/samba/shareexample/ディレクトリの所有者を
EXAMPLE.COM\administrator
に設定し、グループをEXAMPLE.COM\Domain Users
に設定するには、次のコマンドを実行します。sudo chown "EXAMPLE.COM\administrator":"EXAMPLE.COM\Domain Users" /srv/samba/shareexample
-
Samba共有へのアクセス
次のタスクでは、WindowsクライアントとOracle LinuxクライアントからSamba共有にアクセスする方法について説明します。
WindowsクライアントからのSamba共有へのアクセス
Sambaサーバー上の共有にWindowsからアクセスするには、コンピュータまたはWindowsエクスプローラを開き、次の書式を使用してSambaサーバーのホスト名および共有名を入力します:
\\server_name\share_name
\\server_name
を入力すると、Windowsに、サーバーが共有しているディレクトリおよびプリンタが表示されます。また、同じ構文を使用して、ネットワーク・ドライブを共有名にマップできます。
クライアントからのSamba共有へのアクセス
Oracle LinuxホストからSamba共有にアクセスするには、次のパッケージをインストールできます:
-
samba-client
samba-client
パッケージをインストールすると、Samba共有にアクセスするためのSFTPのようなコマンドを提供するsmbclient
ユーティリティが提供されます。たとえば、smbclient
には、リモートSamba共有からファイルをダウンロードするためのget
コマンドと、ファイルをアップロードするためのput
コマンドが用意されています。 -
cifs-utils
cifs-utils
パッケージをインストールすると、Samba共有をマウントできます。
smbclient
コマンドの使用
次のステップでは、smbclient
コマンドの使用方法の概要を示します。
-
アカウントEXAMPLE.COM/user1を使用して、サーバーexample_samba_serverにホストされている共有example_samba_shareにログオンします。
sudo smbclient -U "EXAMPLE.COM\user1" //example_samba_server/example_samba_share
-
ディレクトリの場所/directory1/に移動します。
smb: \> cd /directory1/
-
ファイルExampleFile.txtをダウンロードします:
smb: \directory1\> get ExampleFile.txt
-
セッションを終了します:
smb: \directory1\> exit
詳細は、smbclient(1)
マニュアル・ページを参照してください。
cifs
を使用したSamba共有のマウント
Samba共有をマウントするには、次のようなコマンドを使用します。
sudo mount -t cifs //server_name/share_name mountpoint -o credentials=credfile
前述のコマンドでは、資格証明ファイルにはusername
、password
およびdomain
の設定が含まれています。
username=username
password=password
domain=EXAMPLE.COM
domain
のパラメータには、ドメインまたはワークグループの名前を指定できます。
注意:
資格証明ファイルにはプレーン・テキストのパスワードが含まれるため、chmodを使用して、自分だけがパスワードを読めるようにします。次の例を示します。
sudo chmod 400 credfile
SambaサーバーがADドメイン内のドメイン・メンバー・サーバーで、現行のログイン・セッションがドメイン内のKerberosサーバーによって認証された場合は、資格証明ファイルのかわりにsec=krb5オプションを指定して、既存のセッション資格証明を使用できます:
sudo mount -t cifs //server_name/share_name mountpoint -o sec=krb5
詳細は、mount.cifs(8)
マニュアル・ページを参照してください。