https://wiki.bwhpc.de/wiki/api.php?action=feedcontributions&user=S+Siebler&feedformat=atombwHPC Wiki - User contributions [en]2024-03-29T10:14:53ZUser contributionsMediaWiki 1.31.16https://wiki.bwhpc.de/wiki/index.php?title=SDS@hd/Access/NFS&diff=12532SDS@hd/Access/NFS2024-01-10T10:56:50Z<p>S Siebler: /* Prerequisites */</p>
<hr />
<div>= <b> Prerequisites </b> =<br />
<br />
* '''Attention:''' To access data served by SDS@hd, you need a '''''Service Password'''''. See details [[SDS@hd/Registration]].<br />
<br />
* Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network]. This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
* The access via nfs protocol is machine-based, which means '''new nfs-Clients have to be registered''' on SDS@hd. During this registration each machine receives a keytab file from the SDS@hd team, which allows mounting SDS@hd. In order the keytab file to be created, please [mailto:sds-hd-support@urz.uni-heidelberg.de?subject=SDS@hd%20nfs-Client%20Registration send an email] to SDS@hd team for Clientregistration with the following information:<br />
** hostname of the new nfs-Client<br />
** IP address<br />
** short description<br />
** location<br />
** acronym of the Speichervorhaben which should be available on this machine<br />
<br />
= <b> Using NFSv4 for UNIX client </b> = <br />
<br />
The authentication for data access via NFSv4 is performed using Kerberostickets. This requires a functioning Kerberos environment on the client!<br />
<br />
{{:SDS@hd/Access/Kerberos}}<br />
<br />
After configuring kerberos, you have to install nfs packages in your system, and enable kerberized NFSv4. The exact names of the packages depending on you linux distribution (see examples below).<br />
<br />
''Example RedHat/CentOS''<br />
<pre><br />
> yum install nfs-utils nfs4-acl-tools<br />
<br />
/etc/sysconfig/nfs:<br />
NEED_IDMAPD=yes<br />
NEED_GSSD=yes<br />
</pre><br />
<br />
''Example debian/ubuntu''<br />
<pre><br />
> apt install nfs-common nfs4-acl-tools nfs-server<br />
<br />
/etc/default/nfs-common:<br />
NEED_IDMAPD=yes<br />
NEED_GSSD=yes<br />
</pre><br />
On ubuntu server: nfs-kernel-server<br />
<br />
{{:SDS@hd/Access/ID-Mapping}}<br />
<br />
To enable the ID-Mapping for NFSv4 mounts change the file ''/etc/idmapd.conf'' with the following lines:<br />
<pre><br />
in /etc/idmapd.conf:<br />
[General]<br />
Domain = urz.uni-heidelberg.de<br />
Local-Realms = BWSERVICES.UNI-HEIDELBERG.DE<br />
</pre><br />
<br />
== mount a nfs share ==<br />
The usual restrictions for mounting drives under Linux apply. Usually this can only be done by the superuser "root". For detailed information, please contact the system administrator of your system.<br />
<br />
After successfull configuration (s. 2.1) you can mount your SDS@hd share with the following commands:<br />
<pre><br />
> mkdir <mountpoint><br />
> mount -t nfs4 -o sec=krb5,vers=4.1 lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint><br />
</pre><br />
<br />
To enable the mounting after a restart, you have to add the following line to the file "/etc/fstab"<br />
<pre><br />
lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint> nfs4 sec=krb5,vers=4.1 0 0<br />
</pre><br />
<br />
=== AutoFS Setup ===<br />
<br />
Instead of the fstab-entry you can also use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
sds-hd -fstype=nfs4,rw,sec=krb5,vers=4.1,nosuid,nodev lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02<br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file, e.g.:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the shares.<br />
<br />
== access your data ==<br />
'''Attention!''' The access can not be done as root user, because root uses the Kerberosticket of the machine, which does not have data access! <br />
<br />
To access your data on SDS@hd you have to fetch a valid kerberos ticket with your SDS@hd user and Servicepassword:<br />
<pre><br />
> kinit hd_xy123<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
</pre><br />
You can check afterwards your kerberos ticket with:<br />
<pre><br />
> klist<br />
Ticket cache: FILE:/tmp/krb5cc_1000<br />
Default principal: hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE<br />
<br />
Valid starting Expires Service principal<br />
20.09.2017 04:00:01 21.09.2017 04:00:01 krbtgt/BWSERVICES.UNI-HEIDELBERG.DE@BWSERVICES.UNI-HEIDELBERG.DE<br />
renew until 29.09.2017 13:38:49<br />
</pre><br />
<br />
Afterwards you should be able to access the mountpoint, which contain all Speichervorhaben exported to your machine:<br />
<pre><br />
> ls <mountpoint><br />
sd16j007 sd17c010 sd17d005<br />
</pre><br />
<br />
== renew a kerberos ticket ==<br />
Because a kerberos ticket has a limited lifetime (default: 10 hours, maximum 24 hours) for security reasons, you have to renew your ticket before it expires to prevent access loss.<br />
<pre><br />
> kinit -R<br />
</pre><br />
<br />
This renewal could only be done for maximum time of 10 Days and as long as the current kerberos ticket is still valid. For renewal of an expired ticket, you have to use again your Servicepassword.<br />
<br />
== destroy kerberos ticket ==<br />
Even if kerberos tickets are only valid for a limited period of time, a ticket should be destroyed as soon as access is no longer needed to prevent misuse on multi-user systems:<br />
<pre>kdestroy</pre><br />
<br />
== automated kerberos tickets ==<br />
<span style="color:red"><strong>'''Attention!''' Keep this generated Keytab safe and use it only in trusted environments!</strong></span><br />
<br />
If your workflow needs a permanent access to SDS@hd for longer than 10 Days, you can use '''ktutil''' to encrypt your Service Password into a keytab file:<br />
<br />
''interactive way:''<br />
<pre><br />
ktutil<br />
ktutil: addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e rc4-hmac<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE:<br />
ktutil: addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e aes256-cts<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE:<br />
ktutil: wkt xy123.keytab<br />
ktuitl: quit<br />
</pre><br />
<br />
''non-interactive way:''<br />
<pre><br />
echo -e "addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e rc4-hmac\n<your_servicepasword>\n<br />
addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e aes256-cts\n<your_servicepasword>\nwkt xy123.keytab" | ktutil<br />
</pre><br />
<br />
With this keytab, you can fetch a kerberos ticket without an interactive password:<br />
<pre><br />
kinit -k -t xy123.keytab hd_xy123 <br />
</pre><br />
<br></div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=SDS@hd/Access/WEBDAV&diff=12467SDS@hd/Access/WEBDAV2023-11-21T08:53:40Z<p>S Siebler: </p>
<hr />
<div>It is possible to access the SDS@hd service from Windows, Mac and Linux using the WebDAV protocol. <br />
<br />
This enables easy access to SDS@hd without additional registration of your own computer.<br />
This way can also be useful if you are in a network in which e.g. [[SDS@hd/Access/CIFS|SMB]] and [[SDS@hd/Access/NFS|NFS]] are not available, e.g. due to firewall restrictions, but want a faster and more robust connection then [[SDS@hd/Access/SFTP|SFTP]].<br />
<br />
'''Attention:'''<br />
In principle, however, the connection might not be suitable for permanent connections, since this depends highly on the used client if it is highly available.<br />
Because of this we advise the [https://rclone.org/ Rclone] client.<br />
<br />
= Prerequisites =<br />
<br />
'''Attention:''' To access data served by SDS@hd, you need a '''''Service Password'''''. See details [[SDS@hd/Registration]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the networks of participating organizations, e.g. [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= Installing the WebDAV client Rclone =<br />
Rclone is a command line tool to manage files on cloud storage systems and can easily be used to access SDS@hd.<br />
Detailed instructions how to download and install Rclone can be found [https://rclone.org/install/ here].<br />
<br />
<br />
== ''Quickstart'' ==<br />
Rclone is a Go program and comes as a single binary file.<br />
<br />
* [https://rclone.org/downloads/ Download] the relevant binary. <br />
* Extract the `rclone` executable, `rclone.exe` on Windows, from the archive.<br />
* Run `rclone config` to setup SDS@hd connection. See [https://rclone.org/webdav/ rclone webdav config] docs for more details.<br />
* Optionally configure automatic execution.<br />
<br />
Detailed information regarding different operating systems can be found here:<br />
* [https://rclone.org/install/#script-installation Installation on Linux]<br />
* [https://rclone.org/install/#macos Installation on macOS]<br />
* [https://rclone.org/install/#windows Installation on Windows]<br />
<br />
== ''Configuring the SDS@hd connection:'' ==<br />
<br />
To configure the SDS@hd WebDAV remote you will need to use the following URL for it, and have a valid username and password.<br />
<br />
To add the SDS@hd connection in rclone simply run:<br />
<pre><br />
> rclone config<br />
</pre><br />
This will guide you through an interactive setup process. It is important to use the provided configuration values to get a working SDS@hd connection.<br />
<pre><br />
No remotes found, make a new one?<br />
n) New remote<br />
s) Set configuration password<br />
q) Quit config<br />
n/s/q> n<br />
name> sds-hd<br />
<br />
Type of storage to configure.<br />
Choose a number from below, or type in your own value<br />
[snip]<br />
XX / WebDAV<br />
\ "webdav"<br />
[snip]<br />
Storage> webdav<br />
<br />
URL of http host to connect to<br />
E.g. https://example.com<br />
Enter a value<br />
url> https://lsdf02-webdav.urz.uni-heidelberg.de<br />
<br />
Name of the WebDAV site/service/software you are using<br />
Choose a number from below, or type in your own value<br />
1 / Fastmail Files<br />
\ (fastmail)<br />
2 / Nextcloud<br />
\ (nextcloud)<br />
3 / Owncloud<br />
\ (owncloud)<br />
4 / Sharepoint Online, authenticated by Microsoft account<br />
\ (sharepoint)<br />
5 / Sharepoint with NTLM authentication, usually self-hosted or on-premises<br />
\ (sharepoint-ntlm)<br />
6 / Other site/service or software<br />
\ (other)<br />
vendor> other<br />
<br />
User name<br />
user> <insert sds@hd username, eg. hd_xy123><br />
<br />
Password.<br />
y) Yes type in my own password<br />
g) Generate random password<br />
n) No leave this optional password blank<br />
y/g/n> y<br />
Enter the password:<br />
password: <enter service pwd><br />
Confirm the password:<br />
password: <enter service pwd><br />
<br />
Bearer token instead of user/pass (e.g. a Macaroon)<br />
bearer_token><br />
<br />
Remote config<br />
--------------------<br />
[sds-hd]<br />
type = webdav<br />
url = https://lsdf02-webdav.urz.uni-heidelberg.de<br />
vendor = other<br />
user = hd_xy123<br />
pass = *** ENCRYPTED ***<br />
bearer_token =<br />
--------------------<br />
y) Yes this is OK<br />
e) Edit this remote<br />
d) Delete this remote<br />
y/e/d> y<br />
</pre><br />
After this you can exit the rclone config program.<br />
<br />
= Using Rclone client interactively =<br />
A detailed explanation on how to use Rclone can be found [https://rclone.org/docs/#basic-syntax here]!<br />
<br />
In general the systax to use Rclone is like this:<br />
<pre><br />
Syntax: [options] subcommand <parameters> <parameters...><br />
</pre><br />
Source and destination paths are specified by the name you gave the storage system in the config file (e.g. sds-hd ) then the sub path, e.g. "sds-hd:sd16a0001" to look at Speichervorhaben "sd16a001" on SDS@hd.<br />
<br />
== ''A few examples for an easy start'' ==<br />
list all directories/containers/buckets in the Speichervorhaben sd16a001.<br />
<pre>rclone lsd sds-hd:sd16a001 </pre><br />
<br />
copies /local/path to the remote path on SDS@hd<br />
<pre> rclone copy </local/path> sds-hd:<remote/path> </pre><br />
copies fom remote path on SDS@hd to /local/path<br />
<pre> rclone copy sds-hd:<remote/path> </local/path> </pre> <br />
Moves the contents of the source directory to the destination directory.<br />
<pre> rclone move sds-hd:<source/path> sds-hd:<destination/path> </pre><br />
<br />
More Subcommands can be found [https://rclone.org/docs/#subcommands here].<br />
<br />
= Using Rclone to create local mount =<br />
Mount SDS@hd as file system on a mountpoint.<br />
Detailed information on how to use rclone mount can be found [https://rclone.org/commands/rclone_mount/ here].<br />
<br />
On Linux and macOS, you can run mount in either foreground or background (aka daemon) mode. Mount runs in foreground mode by default. Use the --daemon flag to force background mode. On Windows you can run mount in foreground only, the flag is ignored.<br />
<br />
== ''Using Rclone mount on Linux or macOS'' ==<br />
On Linux or macOS start the mount like this, where /path/to/local/mount is an empty existing directory:<br />
<pre><br />
rclone mount sds-hd:path/to/files /path/to/local/mount<br />
</pre><br />
<br />
== ''Using Rclone mount on Windows'' ==<br />
To run rclone mount on Windows, you will need to download and install [https://winfsp.dev/ WinFsp].<br />
More Information can be found [https://rclone.org/commands/rclone_mount/#installing-on-windows here].<br />
To mount on drive letter X or a nonexistent subdirectory, use:<br />
<pre><br />
rclone mount sds-hd:path/to/files X:<br />
rclone mount sds-hd:path/to/files C:\path\parent\mount<br />
</pre><br />
<br />
<br />
= Best practices =<br />
<br />
Rclone/ WebDAV has a lot of useful options. <br />
<br />
== ''Performance'' ==<br />
<br />
To be able to utilise a bigger bandwidth it is helpful to add the following options for increased performance.<br />
This however does not mean a better download speed for a bigger value!<br />
<pre><br />
--transfers <int><br />
</pre><br />
Number of file transfers to run in parallel (default 4). Depending on local Network, different values might be best. It is advised to not increase over 32 due to increased overhead and a resulting drop in performance.<br />
<br />
<pre><br />
--multi-thread-streams <int> <br />
</pre><br />
<br />
Number of streams to use for multi-thread downloads (default 4). Only important on very large files. This will cause multi-thread up/download on chunk sized bits of the file.<br />
<br />
== ''Debugging and Statistics'' ==<br />
- To get updates on current progress use:<br />
<pre><br />
--stats<br />
</pre><br />
Interval between printing stats, e.g. 500ms, 60s, 5m (0 to disable) (default 1m0s). <br />
<br />
- To get debug information, use:<br />
<pre><br />
--log-level=DEBUG <br />
--stats-log-level=DEBUG<br />
</pre></div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=SDS@hd/Access/WEBDAV&diff=12465SDS@hd/Access/WEBDAV2023-11-20T11:56:00Z<p>S Siebler: Created page with "It is possible to access the SDS@hd service from Windows, Mac and Linux using the WebDAV protocol. This enables easy access to SDS@hd without additional registration of your..."</p>
<hr />
<div>It is possible to access the SDS@hd service from Windows, Mac and Linux using the WebDAV protocol. <br />
<br />
This enables easy access to SDS@hd without additional registration of your own computer.<br />
This way can also be useful if you are in a network in which e.g. [[SDS@hd/Access/CIFS|SMB]] and [[SDS@hd/Access/NFS|NFS]] are not available, e.g. due to firewall restrictions, but want a faster more robust connection then [[SDS@hd/Access/SFTP|SFTP]].<br />
<br />
'''Attention:'''<br />
In principle, however, the connection might not be suitable for permanent connections, since is depends highly on the used client if it is highly available.<br />
Because of this we advise the [https://rclone.org/ Rclone] client.<br />
<br />
= Prerequisites =<br />
<br />
'''Attention:''' To access data served by SDS@hd, You need a '''''Service Password'''''. See details [[SDS@hd/Registration]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the networks of participating Organizations, e.g. [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= Installing the WebDAV client Rclone =<br />
Rclone is a command line tool to manage files on cloud storage systems and can easily be used to access SDS@hd.<br />
Detailed instructions how to download and install Rclone can be found [https://rclone.org/install/ here].<br />
<br />
<br />
== ''Quickstart'' ==<br />
Rclone is a Go program and comes as a single binary file.<br />
<br />
* [https://rclone.org/downloads/ Download] the relevant binary. <br />
* Extract the `rclone` executable, `rclone.exe` on Windows, from the archive.<br />
* Run `rclone config` to setup SDS@hd connection. See [https://rclone.org/webdav/ rclone webdav config] docs for more details.<br />
* Optionally configure automatic execution.<br />
<br />
Detailed information regarding different operating systems can be found here:<br />
* [https://rclone.org/install/#script-installation Installation on Linux]<br />
* [https://rclone.org/install/#macos Installation on macOS]<br />
* [https://rclone.org/install/#windows Installation on Windows]<br />
<br />
== ''Configuring the SDS@hd connection:'' ==<br />
<br />
To configure the SDS@hd WebDAV remote you will need to use the following URL for it, and have a valid username and password.<br />
<br />
To add the SDS@hd connection in rclone simply run:<br />
<pre><br />
> rclone config<br />
</pre><br />
This will guide you through an interactive setup process. It is important to use the provided configuration values to get a working SDS@hd connection.<br />
<pre><br />
No remotes found, make a new one?<br />
n) New remote<br />
s) Set configuration password<br />
q) Quit config<br />
n/s/q> n<br />
name> sds-hd<br />
<br />
Type of storage to configure.<br />
Choose a number from below, or type in your own value<br />
[snip]<br />
XX / WebDAV<br />
\ "webdav"<br />
[snip]<br />
Storage> webdav<br />
<br />
URL of http host to connect to<br />
E.g. https://example.com<br />
Enter a value<br />
url> https://lsdf02-webdav.urz.uni-heidelberg.de<br />
<br />
Name of the WebDAV site/service/software you are using<br />
Choose a number from below, or type in your own value<br />
1 / Fastmail Files<br />
\ (fastmail)<br />
2 / Nextcloud<br />
\ (nextcloud)<br />
3 / Owncloud<br />
\ (owncloud)<br />
4 / Sharepoint Online, authenticated by Microsoft account<br />
\ (sharepoint)<br />
5 / Sharepoint with NTLM authentication, usually self-hosted or on-premises<br />
\ (sharepoint-ntlm)<br />
6 / Other site/service or software<br />
\ (other)<br />
vendor> other<br />
<br />
User name<br />
user> <insert sds@hd username, eg. hd_xy123><br />
<br />
Password.<br />
y) Yes type in my own password<br />
g) Generate random password<br />
n) No leave this optional password blank<br />
y/g/n> y<br />
Enter the password:<br />
password: <enter service pwd><br />
Confirm the password:<br />
password: <enter service pwd><br />
<br />
Bearer token instead of user/pass (e.g. a Macaroon)<br />
bearer_token><br />
<br />
Remote config<br />
--------------------<br />
[sds-hd]<br />
type = webdav<br />
url = https://lsdf02-webdav.urz.uni-heidelberg.de<br />
vendor = other<br />
user = hd_xy123<br />
pass = *** ENCRYPTED ***<br />
bearer_token =<br />
--------------------<br />
y) Yes this is OK<br />
e) Edit this remote<br />
d) Delete this remote<br />
y/e/d> y<br />
</pre><br />
After this you can exit the rclone config program.<br />
<br />
= Using Rclone client interactively =<br />
A detailed explanation on how to use Rclone can be found [https://rclone.org/docs/#basic-syntax here]!<br />
<br />
In general the systax to use Rclone is like this:<br />
<pre><br />
Syntax: [options] subcommand <parameters> <parameters...><br />
</pre><br />
Source and destination paths are specified by the name you gave the storage system in the config file (e.g. sds-hd ) then the sub path, e.g. "sds-hd:sd16a0001" to look at Speichervorhaben "sd16a001" on SDS@hd.<br />
<br />
== ''A few examples for an easy start'' ==<br />
list all directories/containers/buckets in the Speichervorhaben sd16a001.<br />
<pre>rclone lsd sds-hd:sd16a001 </pre><br />
<br />
copies /local/path to the remote path on SDS@hd<br />
<pre> rclone copy </local/path> sds-hd:<remote/path> </pre><br />
copies fom remote path on SDS@hd to /local/path<br />
<pre> rclone copy sds-hd:<remote/path> </local/path> </pre> <br />
Moves the contents of the source directory to the destination directory.<br />
<pre> rclone move sds-hd:<source/path> sds-hd:<destination/path> </pre><br />
<br />
More Subcommands can be found [https://rclone.org/docs/#subcommands here].<br />
<br />
= Using Rclone to create local mount =<br />
Mount SDS@hd as file system on a mountpoint.<br />
Detailed information on how to use rclone mount can be found [https://rclone.org/commands/rclone_mount/ here].<br />
<br />
On Linux and macOS, you can run mount in either foreground or background (aka daemon) mode. Mount runs in foreground mode by default. Use the --daemon flag to force background mode. On Windows you can run mount in foreground only, the flag is ignored.<br />
<br />
== ''Using Rclone mount on Linux or macOS'' ==<br />
On Linux or macOS start the mount like this, where /path/to/local/mount is an empty existing directory:<br />
<pre><br />
rclone mount sds-hd:path/to/files /path/to/local/mount<br />
</pre><br />
<br />
== ''Using Rclone mount on Windows'' ==<br />
To run rclone mount on Windows, you will need to download and install [https://winfsp.dev/ WinFsp].<br />
More Information can be found [https://rclone.org/commands/rclone_mount/#installing-on-windows here].<br />
To mount on drive letter X or a nonexistent subdirectory, use:<br />
<pre><br />
rclone mount sds-hd:path/to/files X:<br />
rclone mount sds-hd:path/to/files C:\path\parent\mount<br />
</pre><br />
<br />
<br />
= Best practices =<br />
<br />
Rclone/ WebDAV has a lot of useful options. <br />
<br />
== ''Performance'' ==<br />
<br />
To be able to utilise a bigger bandwidth it is helpful to add the following options for increased performance.<br />
This however does not mean a better download speed for a bigger value!<br />
<pre><br />
--transfers <int><br />
</pre><br />
Number of file transfers to run in parallel (default 4). Depending on local Network, different values might be best. It is advised to not increase over 32 due to increased overhead and a resulting drop in performance.<br />
<br />
<pre><br />
--multi-thread-streams <int> <br />
</pre><br />
<br />
Number of streams to use for multi-thread downloads (default 4). Only important on very large files. This will cause multi-thread up/download on chunk sized bits of the file.<br />
<br />
== ''Debugging and Statistics'' ==<br />
- To get updates on current progress use:<br />
<pre><br />
--stats<br />
</pre><br />
Interval between printing stats, e.g. 500ms, 60s, 5m (0 to disable) (default 1m0s). <br />
<br />
- To get debug information, use:<br />
<pre><br />
--log-level=DEBUG <br />
--stats-log-level=DEBUG<br />
</pre></div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=SDS@hd/Access&diff=12464SDS@hd/Access2023-11-20T11:46:50Z<p>S Siebler: </p>
<hr />
<div>= Access Protocols =<br />
* [[SDS@hd/Access/SFTP|SFTP/SSHFS (Win,Mac,Linux)]]<br />
* [[SDS@hd/Access/CIFS|SMB/CIFS (Win,Mac,Linux)]]<br />
* [[SDS@hd/Access/NFS|NFSv4 (Linux)]]<br />
* [[SDS@hd/Access/WEBDAV|WebDAV (Win,Mac,Linux)]]<br />
<!-- = Authentication Tools = --><br />
<!-- * [[SDS@hd/Access/Kerberos|Kerberos]] --><br />
<!-- * [[SDS@hd/Access/ID-Mapping|SSSD]] --><br />
<br />
= Access from bwForCluster Helix =<br />
On bwForCluster Helix is possible to directly access your storage space under /mnt/sds-hd/ on all login and compute nodes.</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=SDS@hd/Access/NFS&diff=12450SDS@hd/Access/NFS2023-11-15T08:59:01Z<p>S Siebler: /* mount a nfs share */</p>
<hr />
<div>= <b> Prerequisites </b> =<br />
<br />
* '''Attention:''' To access data served by SDS@hd, You need a '''''Service Password'''''. See details [[SDS@hd/Registration]].<br />
<br />
* Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network]. This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
* The access via nfs protocol is machine-based, which means '''new nfs-Clients have to be registered''' on SDS@hd. During this registration each machine gets a keytab file, which allows mounting SDS@hd.<br />
<br />
* Currently you have to [mailto:sds-hd-support@urz.uni-heidelberg.de?subject=SDS@hd%20nfs-Client%20Registration send an email] for Clientregistration to SDS@hd Team with the following information:<br />
** hostname of the new nfs-Client<br />
** IP address<br />
** short description<br />
** location<br />
** acronym of the Speichervorhaben which should be available on this machine<br />
<br />
= <b> Using NFSv4 for UNIX client </b> = <br />
<br />
The authentication for data access via NFSv4 is performed using Kerberostickets. This requires a functioning Kerberos environment on the client!<br />
<br />
{{:SDS@hd/Access/Kerberos}}<br />
<br />
After configuring kerberos, you have to install nfs packages in your system, and enable kerberized NFSv4. The exact names of the packages depending on you linux distribution (see examples below).<br />
<br />
''Example RedHat/CentOS''<br />
<pre><br />
> yum install nfs-utils nfs4-acl-tools<br />
<br />
/etc/sysconfig/nfs:<br />
NEED_IDMAPD=yes<br />
NEED_GSSD=yes<br />
</pre><br />
<br />
''Example debian/ubuntu''<br />
<pre><br />
> apt install nfs-common nfs4-acl-tools nfs-server<br />
<br />
/etc/default/nfs-common:<br />
NEED_IDMAPD=yes<br />
NEED_GSSD=yes<br />
</pre><br />
On ubuntu server: nfs-kernel-server<br />
<br />
{{:SDS@hd/Access/ID-Mapping}}<br />
<br />
To enable the ID-Mapping for NFSv4 mounts change the file ''/etc/idmapd.conf'' with the following lines:<br />
<pre><br />
in /etc/idmapd.conf:<br />
[General]<br />
Domain = urz.uni-heidelberg.de<br />
Local-Realms = BWSERVICES.UNI-HEIDELBERG.DE<br />
</pre><br />
<br />
== mount a nfs share ==<br />
The usual restrictions for mounting drives under Linux apply. Usually this can only be done by the superuser "root". For detailed information, please contact the system administrator of your system.<br />
<br />
After successfull configuration (s. 2.1) you can mount your SDS@hd share with the following commands:<br />
<pre><br />
> mkdir <mountpoint><br />
> mount -t nfs4 -o sec=krb5,vers=4.1 lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint><br />
</pre><br />
<br />
To enable the mounting after a restart, you have to add the following line to the file "/etc/fstab"<br />
<pre><br />
lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint> nfs4 sec=krb5,vers=4.1 0 0<br />
</pre><br />
<br />
=== AutoFS Setup ===<br />
<br />
Instead of the fstab-entry you can also use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
sds-hd -fstype=nfs4,rw,sec=krb5,vers=4.1,nosuid,nodev lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02<br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file, e.g.:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the shares.<br />
<br />
== access your data ==<br />
'''Attention!''' The access can not be done as root user, because root uses the Kerberosticket of the machine, which does not have data access! <br />
<br />
To access your data on SDS@hd you have to fetch a valid kerberos ticket with your SDS@hd user and Servicepassword:<br />
<pre><br />
> kinit hd_xy123<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
</pre><br />
You can check afterwards your kerberos ticket with:<br />
<pre><br />
> klist<br />
Ticket cache: FILE:/tmp/krb5cc_1000<br />
Default principal: hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE<br />
<br />
Valid starting Expires Service principal<br />
20.09.2017 04:00:01 21.09.2017 04:00:01 krbtgt/BWSERVICES.UNI-HEIDELBERG.DE@BWSERVICES.UNI-HEIDELBERG.DE<br />
renew until 29.09.2017 13:38:49<br />
</pre><br />
<br />
Afterwards you should be able to access the mountpoint, which contain all Speichervorhaben exported to your machine:<br />
<pre><br />
> ls <mountpoint><br />
sd16j007 sd17c010 sd17d005<br />
</pre><br />
<br />
== renew a kerberos ticket ==<br />
Because a kerberos ticket has a limited lifetime (default: 10 hours, maximum 24 hours) for security reasons, you have to renew your ticket before it expires to prevent access loss.<br />
<pre><br />
> kinit -R<br />
</pre><br />
<br />
This renewal could only be done for maximum time of 10 Days and as long as the current kerberos ticket is still valid. For renewal of an expired ticket, you have to use again your Servicepassword.<br />
<br />
== destroy kerberos ticket ==<br />
Even if kerberos tickets are only valid for a limited period of time, a ticket should be destroyed as soon as access is no longer needed to prevent misuse on multi-user systems:<br />
<pre>kdestroy</pre><br />
<br />
== automated kerberos tickets ==<br />
<span style="color:red"><strong>'''Attention!''' Keep this generated Keytab safe and use it only in trusted environments!</strong></span><br />
<br />
If your workflow needs a permanent access to SDS@hd for longer than 10 Days, you can use '''ktutil''' to encrypt your Service Password into a keytab file:<br />
<br />
''interactive way:''<br />
<pre><br />
ktutil<br />
ktutil: addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e rc4-hmac<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE:<br />
ktutil: addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e aes256-cts<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE:<br />
ktutil: wkt xy123.keytab<br />
ktuitl: quit<br />
</pre><br />
<br />
''non-interactive way:''<br />
<pre><br />
echo -e "addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e rc4-hmac\n<your_servicepasword>\n<br />
addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e aes256-cts\n<your_servicepasword>\nwkt xy123.keytab" | ktutil<br />
</pre><br />
<br />
With this keytab, you can fetch a kerberos ticket without an interactive password:<br />
<pre><br />
kinit -k -t xy123.keytab hd_xy123 <br />
</pre><br />
<br></div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=SDS@hd/Access/CIFS&diff=12378SDS@hd/Access/CIFS2023-09-28T07:01:18Z<p>S Siebler: /* Prerequisites */</p>
<hr />
<div>= Prerequisites =<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[SDS@hd/Registration]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the networks of participating Organizations, e.g. [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
The SMB connection has to be established at least with Protocolversion SMB2.02, which is available since Windows Vista or OSX 10.7, and a [https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level NTLMv2 Authentication Level] of "Send NTLMv2 responses only"<br />
<br />
= Using SMB/CIFS for Windows client =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!--<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
--><br />
<br><br />
<br />
= Using SMB/CIFS for Mac OS client =<br />
<br />
'''Important''' To use SMB Protocol you need a OSX Version 10.7 or newer!<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!-- path outdated:<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
--><br />
<br />
= Using SMB/CIFS for UNIX client =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[SDS@hd/Access/Kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[SDS@hd/Access/CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0,mfsymlinks //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,mfsymlinks,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[SDS@hd/Access/Kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[SDS@hd/Access/ID-Mapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[SDS@hd/Access/ID-Mapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[SDS@hd/Access/NFS#access_your_data|SDS@hd kerberos]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=SDS@hd/Access/CIFS&diff=12377SDS@hd/Access/CIFS2023-09-28T07:01:00Z<p>S Siebler: /* Prerequisites */</p>
<hr />
<div>= Prerequisites =<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[SDS@hd/Registration]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the neworks of participating Organizations, e.g. [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
The SMB connection has to be established at least with Protocolversion SMB2.02, which is available since Windows Vista or OSX 10.7, and a [https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level NTLMv2 Authentication Level] of "Send NTLMv2 responses only"<br />
<br />
= Using SMB/CIFS for Windows client =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!--<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
--><br />
<br><br />
<br />
= Using SMB/CIFS for Mac OS client =<br />
<br />
'''Important''' To use SMB Protocol you need a OSX Version 10.7 or newer!<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!-- path outdated:<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
--><br />
<br />
= Using SMB/CIFS for UNIX client =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[SDS@hd/Access/Kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[SDS@hd/Access/CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0,mfsymlinks //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,mfsymlinks,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[SDS@hd/Access/Kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[SDS@hd/Access/ID-Mapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[SDS@hd/Access/ID-Mapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[SDS@hd/Access/NFS#access_your_data|SDS@hd kerberos]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=SDS@hd/Access/SFTP&diff=12376SDS@hd/Access/SFTP2023-09-28T06:59:43Z<p>S Siebler: /* Prerequisites */</p>
<hr />
<div>It is possible to access the SDS@hd service from Windows, Mac and Linux using the sshfs/sftp protocol. <br />
<br />
This enables easy access to SDS@hd without additional registration of your own computer.<br />
This way can also be useful if you are in a network in which e.g. [[SDS@hd/Access/CIFS|SMB]] and [[SDS@hd/Access/NFS|NFS]] are not available, e.g. due to firewall restrictions.<br />
<br />
'''Attention:'''<br />
In principle, however, the connection is not suitable for permanent connections, since (due to technical reasons) it is not highly available.<br />
<br />
= Prerequisites =<br />
<br />
'''Attention:''' To access data served by SDS@hd, You need a '''''Service Password'''''. See details [[SDS@hd/Registration]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the networks of participating Organizations, e.g. [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= Using SFTP from Linux client =<br />
<br />
== ''direct/interactive Access:'' ==<br />
<br />
You can directly use sftp to "login" to SDS@hd. This will give you an interactive sftp-shell.<br />
<br />
''Example:''<br />
<pre><br />
> sftp hd_xy123@lsdf02-sshfs.urz.uni-heidelberg.de<br />
Connected to lsdf02-sshfs.urz.uni-heidelberg.de.<br />
sftp> ls<br />
sd16j007 sd17c010 sd17d005 <br />
sftp> <br />
sftp> help<br />
...<br />
sftp> put myfile<br />
sftp> get myfile<br />
</pre><br />
<br />
== ''mounting network drive over SFTP:'' ==<br />
<br />
In most linux distributions you could install a package for fuse mounting a network drive. This allows you to work with SDS@hd comparable to a local folder.<br />
<br />
''Example (debian/ubuntu):''<br />
<pre><br />
> apt-get install sshfs<br />
> mkdir ~/sds-hd<br />
> sshfs -o reconnect hd_xy123@lsdf02-sshfs.urz.uni-heidelberg.de: ~/sds-hd<br />
> ls ~/sds-hd<br />
sd16j007 sd17c010 sd17d005 <br />
> touch ~/sds-hd/sd16j007/testfile<br />
</pre><br />
<br />
''Example (CentOS/RedHat):''<br />
<pre><br />
> yum install fuse-sshfs<br />
> mkdir ~/sds-hd<br />
> sshfs -o reconnect hd_xy123@lsdf02-sshfs.urz.uni-heidelberg.de: ~/sds-hd<br />
> ls ~/sds-hd<br />
sd16j007 sd17c010 sd17d005<br />
> touch ~/sds-hd/sd16j007/testfile<br />
</pre><br />
<br />
You can close/unmount the network drive with the command:<br />
<pre><br />
fusermount -u ~/sds-hd<br />
</pre><br />
<br />
You can of course also use /etc/fstab for mounting SDS@hd with the following entry:<br />
<pre><br />
sshfs#hd_xy123@lsdf02-sshfs.urz.uni-heidelberg.de: <your_local_mountpoint> fuse defaults,user,noauto,exec,reconnect 0 0 <br />
</pre><br />
<br />
= Using SFTP from Windows and Mac client =<br />
<br />
Windows clients do not have a SCP/SFTP client installed by default, so it needs to be installed before this protocol can be used. <br />
<br />
'''Tools for example:'''<br />
* [http://www.openssh.com/ OpenSSH] <br />
*[http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty suite] (for Windows and Unix)<br />
*[http://winscp.net/eng/download.php WinSCP] (for Windows)<br />
*[https://filezilla-project.org/download.php?show_all=1 FileZilla] (for Windows, Mac and Linux)<br />
*[https://mobaxterm.mobatek.net MobaXterm] (for Windows)<br />
<br><br />
'''network drive over SFTP:'''<br />
*[http://www.southrivertechnologies.com/download/downloadwd.html WebDrive] (for Windows, Mac, iOS, Android) <br />
*[http://www.sftpnetdrive.com/ SFTPNetDrive] (for Windows)<br />
*[http://www.netdrive.net/ NetDrive] (for Windows)<br />
*[http://www.expandrive.com/expandrive ExpanDrive] (for Windows, Mac and Linux)<br />
*[https://mountainduck.io/ MountainDuck] (for Windows and Mac)<br />
<br />
== Connecting to SDS@hd ==<br />
<br />
To establish a connection to SDS@hd you have to use the following parameters:<br />
* protocol: sftp<br />
* port: 22<br />
* hostname: lsdf02-sshfs.urz.uni-heidelberg.de<br />
* username: <your_username> e.g. hd_xy123<br />
* password: <your_servicepassword><br />
<br />
= Best practices =<br />
<br />
ssh/sftp has a lot of useful options. One of the important ones is the used encryption cipher.<br />
<br />
Changing the encryption method (cipher) can have a significant impact on the transmission speed. The effects are difficult to predict because, among other things, they are depending on the client's processor. In tests on current Intel hardware (Intel (R) Xeon (R) CPU E5-2620 v4), the following ciphers turned out to be particularly fast: <br />
<br />
{| class="wikitable"<br />
!Cipher <br />
!style="text-align:left;"| performance<br />
|-<br />
|chacha20-poly1305@openssh.com (default)<br />
| 100%<br />
|-<br />
|aes128-gcm@openssh.com<br />
|~200%<br />
|-<br />
|aes128-ctr<br />
|~188%<br />
|-<br />
|arcfour<br />
|~135%<br />
|-<br />
|}<br />
<br />
With ssh/sshfs you can use different ciphers with the -o option:<br />
<pre>sshfs -o Cipher=aes128-gcm@openssh.com -o reconnect hd_xy123@lsdf02-sshfs.urz.uni-heidelberg.de: <local_mountpoint></pre><br />
<br />
A list of available ciphers should be available with the command<br />
<pre>ssh -Q cipher</pre><br />
<br><br />
'''Attention:'''<br />
It has to be noted, that not all encryption methods meet the same security requirements. You have to consider the different performance and security requirements for your indiviual usecase.</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=SDS@hd&diff=12375SDS@hd2023-09-28T06:54:16Z<p>S Siebler: dienstöffnung</p>
<hr />
<div>[[File:sds-hd-logo.png|350px]]<br />
<br />
SDS@hd is a central service for securely storing scientific data (Scientific Data Storage). The service is provided as a state service to researchers of higher education institutions of Baden-Württemberg. It is intended to be used for data that is frequently accessed ('hot data').<br />
<br />
{| style=" background:#FEF4AB; width:100%;" <br />
| style="padding:8px; background:#FFE856; font-size:120%; font-weight:bold; text-align:left" | News<br />
|-<br />
| <br />
* November 2022: No special entitlement is needed anymore to participate in an existing storage project.<br />
* September 2023: Service has now been opened for DFN AAI & eduGAIN federation members to participate on existing storage projects.<br />
|}<br />
<br />
{| style=" background:#eeeefe; width:100%;" <br />
| style="padding:8px; background:#dedefe; font-size:120%; font-weight:bold; text-align:left" | Training & Support<br />
|-<br />
| <br />
* [https://www.urz.uni-heidelberg.de/en/service-catalogue/storage/sdshd-scientific-data-storage Service description & FAQ]<br />
* [mailto:sds-hd-support@urz.uni-heidelberg.de Submit a Ticket]<br />
|}<br />
<br />
{| style=" background:#ffeaef; width:100%;"<br />
| style="padding:8px; background:#f5dfdf; font-size:120%; font-weight:bold; text-align:left" | User Documentation<br />
|-<br />
|<br />
* [[SDS@hd/Registration|Registration]]<br />
* [[SDS@hd/Access|Access]]<br />
* [[SDS@hd/Security|Data Security]]<br />
* Visualization: [https://www.bwvisu.de/ bwVisu]<br />
|}<br />
<br />
{| style=" background:#e6e9eb; width:100%;"<br />
| style="padding:8px; background:#d1dadf; font-size:120%; font-weight:bold; text-align:left" | Storage Funding<br />
|-<br />
|<br />
* Please [[SDS@hd/Acknowledgement|acknowledge]] SDS@hd in your publications.</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=SDS@hd/Registration&diff=11677SDS@hd/Registration2022-12-14T14:05:05Z<p>S Siebler: update entitlement requirements</p>
<hr />
<div>Granting access and issuing a user account for '''''SDS@hd''''' requires the registration at the bwServices website [https://bwservices.uni-heidelberg.de/ https://bwservices.uni-heidelberg.de] (step 2).<br />
<br />
= Storageproject (Speichervorhaben) =<br />
<br />
Before you can use SDS@hd you will have to register for a new "Speichervorhaben" or contribute to an already existing project on [https://sds-hd.urz.uni-heidelberg.de/management SDS@hd Managementtool].<br />
<br />
== Register a new "SV" ==<br />
<br />
Typically done only by the leader of a scientific work group or the senior scientist of a research group/collaboration.<br />
Any amount of co-workers can join your SV without having to register another project. <br />
<br />
Your own high school or university has to grant you the permission to start an own SDS@hd Storageproject ("SDS@hd SV entitlement"). <br />
<br />
Each university has their own procedure. <br />
<br />
For more details about the SDS@hd entitlements you can take a look at the [https://urz.uni-heidelberg.de/en/sds-hd SDS@hd Website]<br />
<!-- not yet completed<br />
The page [[Sds_hd_Entitlement]] contains a list of participating high schools and links to instructions on how to get an SDS@hd entitlement at each of them.<br />
--><br />
<br />
If you register your own SV, you will be:<br />
# held accountable for the co-workers in the SV<br />
# asked to provide information for the two reports required by the DFG for their funding of SDS@hd<br />
# likely asked for a contribution to a future DFG grant proposal for an extension of the storage system in your area of research ("wissenschaftliches Beiblatt")<br />
<br />
== Become Coworker of an "SV"==<br />
<br />
Your advisor (the "SV" responsible") will provide you with the following data on the SV:<br />
* acronym<br />
* password<br />
<br />
To become coworker of an ''SV'', please login at<br />
* [https://sds-hd.urz.uni-heidelberg.de/management/index.php?mode=mitarbeit SDS@hd Managementtool] and provide acronym and password. <br />
<br />
You will be assigned to the 'SV' as a member.<br />
<br />
After submitting the request you will receive an email about the further steps. <br />
The SV owner and any managers will be notified automatically.<br />
<br />
= Personal registration for SDS@hd =<br />
<br />
After step 1 you have to register your personal account on the storage system and set a service password.<br />
Please visit: <br />
* [https://bwservices.uni-heidelberg.de/ https://bwservices.uni-heidelberg.de] <br />
*# Select your home organization from the list and click '''Proceed'''<br />
*# You will be directed to the ''Identity Provider'' of your home organisation <br />
*# Enter your home-organisational user ID / username and your home-organisational password and click '''Login''' button<br />
*# You will be redirected back to the registration website [https://bwservices.uni-heidelberg.de/ https://bwservices.uni-heidelberg.de/] <br />
*# <div>Select unter '''The following services are available''' the service '''SDS@hd - Scientific Data Storage''' <br />
*# Click '''Register'''<br />
*# Finally, set a service password for authentication on SDS@hd<br />
<br />
[[File:Sds_bwservices_servicepassword.png]]<br />
<br/><br />
<br />
== Changing Password ==<br />
<br />
At any time, you can set a new SDS@hd service password via the registration website [https://bwservices.uni-heidelberg.de/ https://bwservices.uni-heidelberg.de] by carrying out the following steps:<br />
# visit [https://bwservices.uni-heidelberg.de/ https://bwservices.uni-heidelberg.de] and select your home organization <br />
# authenticate yourself via your home-organizational user id / username and your home-organizational password<br />
# find on the left side '''SDS@hd''' and select '''Set Service Password'''<br />
# set new service password, repeat it and click '''Save''' button.<br />
# the page answers e.g. "Das Passwort wurde bei dem Dienst geändert" ("password has been changed")</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Helix/Filesystems&diff=11573Helix/Filesystems2022-12-07T15:59:25Z<p>S Siebler: /* Workspaces */</p>
<hr />
<div>== Overview ==<br />
<br />
The cluster storage system provides a large parallel file system based on [https://www.ibm.com/support/knowledgecenter/STXKQY/ibmspectrumscale_welcome.html IBM Spectrum Scale] <br />
for $HOME, for workspaces, and for temporary storage via the $TMPDIR environment variable.<br />
<br />
{| class="wikitable"<br />
|- <br />
!style="width:16%" |<br />
!style="width:28%"| $HOME<br />
!style="width:28%"| Workspaces<br />
!style="width:28%"| $TMPDIR<br />
|-<br />
!scope="column" | Visibility<br />
| global<br />
| global<br />
| local<br />
|-<br />
!scope="column" | Lifetime<br />
| permanent<br />
| workspace lifetime<br />
| batch job walltime<br />
|-<br />
!scope="column" | Quotas<br />
| 200 GB<br />
| 10 TB<br />
| none<br />
|-<br />
!scope="column" | Backup<br />
| no<br />
| no<br />
| no<br />
|}<br />
<br />
* global: all nodes access the same file system.<br />
* local: each node has its own temporary file space.<br />
* permanent: files are stored permanently.<br />
* workspace lifetime: files are removed at end of workspace lifetime.<br />
* batch job walltime: files are removed at end of the batch job.<br />
<br />
== $HOME ==<br />
<br />
Home directories are meant for permanent storage of files that are kept being used like source codes, configuration files, executable programs. There is currently no backup for the home directory. The disk space per user is limited to 200 GB. The used disk space is displayed with the command:<br />
<br />
<code>homequotainfo</code><br />
<br />
== Workspaces ==<br />
<br />
Workspace tools can be used to get temporary space for larger amounts of data necessary for or produced by running jobs. To create a workspace you need to supply a name for the workspace and a lifetime in days. The maximum lifetime is 30 days. It is possible to extend the lifetime 10 times.<br />
<br />
{| class="wikitable"<br />
|- <br />
!style="width:30%" | Command<br />
!style="width:70%"| Action<br />
|-<br />
|ws_allocate -r 7 -m <email> foo 10 <br />
|Allocate a workspace named foo for 10 days and set a email reminder 7 days before expiring. <br />
'''Important:''' You should add your email address and a relative date for notification!<br />
|-<br />
|ws_list -a<br />
|List all your workspaces.<br />
|-<br />
|ws_find foo<br />
|Get absolute path of workspace foo.<br />
|-<br />
|ws_extend foo 5<br />
|Extend lifetime of workspace foo by 5 days from now.<br />
|-<br />
|ws_release foo<br />
|Manually erase your workspace foo.<br />
|-<br />
|ws_send_ical -m <email> foo<br />
|sending a .ical calendar entry for reminding workspace expiring <br />
|-<br />
|ws_share share/unshare/unshare-all <workspacename> <username> [username2]<br />
|ws_share allows to share an existing workspace with other users. <br />
|-<br />
|}<br />
<br />
If you plan to produce or copy large amounts of data in workspaces, please check the availability. The used and free disk space on the workspace filesystem is displayed with the command:<br />
<br />
<code>workquotainfo</code><br />
<br />
==== Restoring expired Workspaces ====<br />
At expiration time your workspace will be moved to a special, hidden directory. For a short period of time you can still restore your data into a valid workspace. For that, use<br />
<pre><br />
ws_restore -l<br />
</pre><br />
to get a list of your expired workspaces, and then restore them into an '''existing, active workspace''' <code>restored_ws</code>:<br />
<pre><br />
ws_restore <deleted_workspacename> restored_ws<br />
</pre><br />
NOTE: the expired workspace has to be specified using the full name as listed by <code>ws_restore -l</code>, including username prefix and timestamp suffix (otherwise, it cannot be uniquely identified).<br />
The target workspace, on the other hand, must be given with just its short name as listed by <code>ws_list</code>, without the username prefix.<br />
<br />
NOTE: <code>ws_restore</code> can only work on the same filesystem! So you have to ensure that the new workspace allocated with <code>ws_allocate</code> is placed on the same filesystem as the expired workspace. Therefor you can use <code>-F <filesystem></code> flag if needed.<br />
<br />
==== Linking workspaces in Home ====<br />
It might be valuable to have links to personal workspaces within a certain directory, e.g., the user home directory. The command <br />
<pre><br />
ws_register <DIR><br />
</pre><br />
will create and manage links to all personal workspaces within in the directory <DIR>. Calling this command will do the following:<br />
<br />
* The directory <DIR> will be created if necessary<br />
* Links to all personal workspaces will be managed:<br />
** Creates links to all available workspaces if not already present<br />
** Removes links to released workspaces<br />
<br />
==== Sharing Workspaces ====<br />
To simplify sharing of workspaces you can use the command<br />
<pre><br />
ws_share<br />
</pre><br />
<br />
This tool setup the needed ACLs on the workspace to allow read-only access to the specified users.<br />
<br />
If you need more specific permissions, you can also setup the ACLs on your own, like described here:<br />
https://wiki.bwhpc.de/e/Workspace#Sharing_Workspace_Data_within_your_Workgroup<br />
<br />
==== Troubleshooting ====<br />
If you are getting the error:<br />
<pre><br />
Error: could not create workspace directory!<br />
</pre><br />
you should check the localesetting of your ssh client. Some clients (e.g. the one from MacOSX) set values that are not valid. You should overwrite LC_CTYPE and set it to a valid locale value like:<br />
<pre><br />
export LC_CTYPE=de_DE.UTF-8<br />
</pre><br />
To make this change persistent you can add this line also to your <code>.bashrc</code> file.<br />
<br />
A list of valid locales can be retrieved via<br />
<pre><br />
locale -a<br />
</pre><br />
<br />
If you are getting the error:<br />
<pre><br />
Error: only root can do this <workspacename><br />
</pre><br />
ensure that you are using the FULL workspacename, including your account_prefix, e.g. "hd_ab123-workspacename"<br />
<br />
== $TMPDIR ==<br />
<br />
The variable $TMPDIR provides file space for temporary data of running jobs.<br />
Each node has its own $TMPDIR. <!-- It is possible to request a global $TMPDIR for a job. --><br />
The data in $TMPDIR become unavailable as soon as the job has finished.<br />
<br />
== Access to SDS@hd ==<br />
<br />
It is possible to access your storage space on [http://sds-hd.urz.uni-heidelberg.de SDS@hd] directly on the bwForCluster Helix in /mnt/sds-hd/ on all login and compute nodes.</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Helix/Filesystems&diff=11572Helix/Filesystems2022-12-07T15:55:22Z<p>S Siebler: /* Workspaces */</p>
<hr />
<div>== Overview ==<br />
<br />
The cluster storage system provides a large parallel file system based on [https://www.ibm.com/support/knowledgecenter/STXKQY/ibmspectrumscale_welcome.html IBM Spectrum Scale] <br />
for $HOME, for workspaces, and for temporary storage via the $TMPDIR environment variable.<br />
<br />
{| class="wikitable"<br />
|- <br />
!style="width:16%" |<br />
!style="width:28%"| $HOME<br />
!style="width:28%"| Workspaces<br />
!style="width:28%"| $TMPDIR<br />
|-<br />
!scope="column" | Visibility<br />
| global<br />
| global<br />
| local<br />
|-<br />
!scope="column" | Lifetime<br />
| permanent<br />
| workspace lifetime<br />
| batch job walltime<br />
|-<br />
!scope="column" | Quotas<br />
| 200 GB<br />
| 10 TB<br />
| none<br />
|-<br />
!scope="column" | Backup<br />
| no<br />
| no<br />
| no<br />
|}<br />
<br />
* global: all nodes access the same file system.<br />
* local: each node has its own temporary file space.<br />
* permanent: files are stored permanently.<br />
* workspace lifetime: files are removed at end of workspace lifetime.<br />
* batch job walltime: files are removed at end of the batch job.<br />
<br />
== $HOME ==<br />
<br />
Home directories are meant for permanent storage of files that are kept being used like source codes, configuration files, executable programs. There is currently no backup for the home directory. The disk space per user is limited to 200 GB. The used disk space is displayed with the command:<br />
<br />
<code>homequotainfo</code><br />
<br />
== Workspaces ==<br />
<br />
Workspace tools can be used to get temporary space for larger amounts of data necessary for or produced by running jobs. To create a workspace you need to supply a name for the workspace and a lifetime in days. The maximum lifetime is 30 days. It is possible to extend the lifetime 10 times.<br />
<br />
{| class="wikitable"<br />
|- <br />
!style="width:30%" | Command<br />
!style="width:70%"| Action<br />
|-<br />
|ws_allocate -r 7 -m <email> foo 10 <br />
|Allocate a workspace named foo for 10 days and set a email reminder 7 days before expiring. <br />
'''Important:''' You should add your email address and a relative date for notification!<br />
|-<br />
|ws_list -a<br />
|List all your workspaces.<br />
|-<br />
|ws_find foo<br />
|Get absolute path of workspace foo.<br />
|-<br />
|ws_extend foo 5<br />
|Extend lifetime of workspace foo by 5 days from now.<br />
|-<br />
|ws_release foo<br />
|Manually erase your workspace foo.<br />
|-<br />
|ws_send_ical -m <email> foo<br />
|sending a .ical calendar entry for reminding workspace expiring <br />
|-<br />
|ws_share share/unshare/unshare-all <workspacename> <username> [username2]<br />
|ws_share allows to share an existing workspace with other users. <br />
|-<br />
|}<br />
<br />
If you plan to produce or copy large amounts of data in workspaces, please check the availability. The used and free disk space on the workspace filesystem is displayed with the command:<br />
<br />
<code>workquotainfo</code><br />
<br />
==== Restoring expired Workspaces ====<br />
At expiration time your workspace will be moved to a special, hidden directory. For a short period of time you can still restore your data into a valid workspace. For that, use<br />
<pre><br />
ws_restore -l<br />
</pre><br />
to get a list of your expired workspaces, and then restore them into an '''existing, active workspace''' <code>restored_ws</code>:<br />
<pre><br />
ws_restore <deleted_workspacename> restored_ws<br />
</pre><br />
NOTE: the expired workspace has to be specified using the full name as listed by <code>ws_restore -l</code>, including username prefix and timestamp suffix (otherwise, it cannot be uniquely identified).<br />
The target workspace, on the other hand, must be given with just its short name as listed by <code>ws_list</code>, without the username prefix.<br />
<br />
NOTE: <code>ws_restore</code> can only work on the same filesystem! So you have to ensure that the new workspace allocated with <code>ws_allocate</code> is placed on the same filesystem as the expired workspace. Therefor you can use <code>-F <filesystem></code> flag if needed.<br />
<br />
==== Linking workspaces in Home ====<br />
It might be valuable to have links to personal workspaces within a certain directory, e.g., the user home directory. The command <br />
<pre><br />
ws_register <DIR><br />
</pre><br />
will create and manage links to all personal workspaces within in the directory <DIR>. Calling this command will do the following:<br />
<br />
* The directory <DIR> will be created if necessary<br />
* Links to all personal workspaces will be managed:<br />
** Creates links to all available workspaces if not already present<br />
** Removes links to released workspaces<br />
<br />
==== Troubleshooting ====<br />
If you are getting the error:<br />
<pre><br />
Error: could not create workspace directory!<br />
</pre><br />
you should check the localesetting of your ssh client. Some clients (e.g. the one from MacOSX) set values that are not valid. You should overwrite LC_CTYPE and set it to a valid locale value like:<br />
<pre><br />
export LC_CTYPE=de_DE.UTF-8<br />
</pre><br />
To make this change persistent you can add this line also to your <code>.bashrc</code> file.<br />
<br />
A list of valid locales can be retrieved via<br />
<pre><br />
locale -a<br />
</pre><br />
<br />
If you are getting the error:<br />
<pre><br />
Error: only root can do this <workspacename><br />
</pre><br />
ensure that you are using the FULL workspacename, including your account_prefix, e.g. "hd_ab123-workspacename"<br />
<br />
== $TMPDIR ==<br />
<br />
The variable $TMPDIR provides file space for temporary data of running jobs.<br />
Each node has its own $TMPDIR. <!-- It is possible to request a global $TMPDIR for a job. --><br />
The data in $TMPDIR become unavailable as soon as the job has finished.<br />
<br />
== Access to SDS@hd ==<br />
<br />
It is possible to access your storage space on [http://sds-hd.urz.uni-heidelberg.de SDS@hd] directly on the bwForCluster Helix in /mnt/sds-hd/ on all login and compute nodes.</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Helix/Filesystems&diff=11203Helix/Filesystems2022-10-12T08:08:05Z<p>S Siebler: /* Troubleshooting */</p>
<hr />
<div>== Overview ==<br />
<br />
The cluster storage system provides a large parallel file system based on [https://www.ibm.com/support/knowledgecenter/STXKQY/ibmspectrumscale_welcome.html IBM Spectrum Scale] <br />
for $HOME, for workspaces, and for temporary storage via the $TMPDIR environment variable.<br />
<br />
{| class="wikitable"<br />
|- <br />
!style="width:16%" |<br />
!style="width:28%"| $HOME<br />
!style="width:28%"| Workspaces<br />
!style="width:28%"| $TMPDIR<br />
|-<br />
!scope="column" | Visibility<br />
| global<br />
| global<br />
| local<br />
|-<br />
!scope="column" | Lifetime<br />
| permanent<br />
| workspace lifetime<br />
| batch job walltime<br />
|-<br />
!scope="column" | Quotas<br />
| 200 GB<br />
| 10 TB<br />
| none<br />
|-<br />
!scope="column" | Backup<br />
| no<br />
| no<br />
| no<br />
|}<br />
<br />
* global: all nodes access the same file system.<br />
* local: each node has its own temporary file space.<br />
* permanent: files are stored permanently.<br />
* workspace lifetime: files are removed at end of workspace lifetime.<br />
* batch job walltime: files are removed at end of the batch job.<br />
<br />
== $HOME ==<br />
<br />
Home directories are meant for permanent storage of files that are kept being used like source codes, configuration files, executable programs. There is currently no backup for the home directory. The disk space per user is limited to 200 GB. The used disk space is displayed with the command:<br />
<br />
<code>homequotainfo</code><br />
<br />
== Workspaces ==<br />
<br />
Workspace tools can be used to get temporary space for larger amounts of data necessary for or produced by running jobs. To create a workspace you need to supply a name for the workspace and a lifetime in days. The maximum lifetime is 30 days. It is possible to extend the lifetime 10 times.<br />
<br />
{| class="wikitable"<br />
|- <br />
!style="width:30%" | Command<br />
!style="width:70%"| Action<br />
|-<br />
|ws_allocate -r 7 -m <email> foo 10 <br />
|Allocate a workspace named foo for 10 days and set a email reminder 7 days before expiring. <br />
'''Important:''' You should add your email address and a relative date for notification!<br />
|-<br />
|ws_list -a<br />
|List all your workspaces.<br />
|-<br />
|ws_find foo<br />
|Get absolute path of workspace foo.<br />
|-<br />
|ws_extend foo 5<br />
|Extend lifetime of workspace foo by 5 days from now.<br />
|-<br />
|ws_release foo<br />
|Manually erase your workspace foo.<br />
|-<br />
|ws_send_ical -m <email> foo<br />
|sending a .ical calendar entry for reminding workspace expiring <br />
|-<br />
|}<br />
<br />
If you plan to produce or copy large amounts of data in workspaces, please check the availability. The used and free disk space on the workspace filesystem is displayed with the command:<br />
<br />
<code>workquotainfo</code><br />
<br />
==== Restoring expired Workspaces ====<br />
At expiration time your workspace will be moved to a special, hidden directory. For a short period of time you can still restore your data into a valid workspace. For that, use<br />
<pre><br />
ws_restore -l<br />
</pre><br />
to get a list of your expired workspaces, and then restore them into an '''existing, active workspace''' <code>restored_ws</code>:<br />
<pre><br />
ws_restore <deleted_workspacename> restored_ws<br />
</pre><br />
NOTE: the expired workspace has to be specified using the full name as listed by <code>ws_restore -l</code>, including username prefix and timestamp suffix (otherwise, it cannot be uniquely identified).<br />
The target workspace, on the other hand, must be given with just its short name as listed by <code>ws_list</code>, without the username prefix.<br />
<br />
NOTE: <code>ws_restore</code> can only work on the same filesystem! So you have to ensure that the new workspace allocated with <code>ws_allocate</code> is placed on the same filesystem as the expired workspace. Therefor you can use <code>-F <filesystem></code> flag if needed.<br />
<br />
==== Linking workspaces in Home ====<br />
It might be valuable to have links to personal workspaces within a certain directory, e.g., the user home directory. The command <br />
<pre><br />
ws_register <DIR><br />
</pre><br />
will create and manage links to all personal workspaces within in the directory <DIR>. Calling this command will do the following:<br />
<br />
* The directory <DIR> will be created if necessary<br />
* Links to all personal workspaces will be managed:<br />
** Creates links to all available workspaces if not already present<br />
** Removes links to released workspaces<br />
<br />
==== Troubleshooting ====<br />
If you are getting the error:<br />
<pre><br />
Error: could not create workspace directory!<br />
</pre><br />
you should check the localesetting of your ssh client. Some clients (e.g. the one from MacOSX) set values that are not valid. You should overwrite LC_CTYPE and set it to a valid locale value like:<br />
<pre><br />
export LC_CTYPE=de_DE.UTF-8<br />
</pre><br />
To make this change persistent you can add this line also to your <code>.bashrc</code> file.<br />
<br />
A list of valid locales can be retrieved via<br />
<pre><br />
locale -a<br />
</pre><br />
<br />
If you are getting the error:<br />
<pre><br />
Error: only root can do this <workspacename><br />
</pre><br />
ensure that you are using the FULL workspacename, including your account_prefix, e.g. "hd_ab123-workspacename"<br />
<br />
== $TMPDIR ==<br />
<br />
The variable $TMPDIR provides file space for temporary data of running jobs.<br />
Each node has its own $TMPDIR. <!-- It is possible to request a global $TMPDIR for a job. --><br />
The data in $TMPDIR become unavailable as soon as the job has finished.<br />
<br />
== Access to SDS@hd ==<br />
<br />
It is possible to access your storage space on [http://sds-hd.urz.uni-heidelberg.de SDS@hd] directly on the bwForCluster Helix in /mnt/sds-hd/ on all login and compute nodes.</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Registration/SSH&diff=10264Registration/SSH2022-03-30T13:28:13Z<p>S Siebler: /* Revoke/Delete SSH Key */</p>
<hr />
<div>{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
This process is only necessary for the bwUniCluster and the bwForCluster MLS&WISO.<br />
On the other clusters, SSH keys can still be copied to the <code>authorized_keys</code> file.<br />
|}<br />
<br />
<br />
= Registering SSH Keys with your Cluster =<br />
<br />
{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
Interactive SSH Keys are not valid all the time, but only for one hour after the last 2-factor login.<br />
They have to be "unlocked" by entering the OTP and service password.<br />
|}<br />
<br />
'''SSH Keys''' are a mechanism for logging into a computer system without having to enter a password. Instead of authenticating yourself with something you know (a password), you prove your identity by showing the server something you have (a cryptographic key).<br />
<br />
The usual process is the following:<br />
<br />
* The user generates a pair of SSH Keys, a private key and a public key, on their local system. The private key never leaves the local system.<br />
<br />
* The user then logs into the remote system using the remote system password and adds the public key to a file called ~/.ssh/authorized_keys .<br />
<br />
* All following logins will no longer require the entry of the remote system password because the local system can prove to the remote system that it has a private key matching the public key on file.<br />
<br />
While SSH Keys have many advantages, the concept also has '''a number of issues''' which make it hard to handle them securely:<br />
<br />
* The private key on the local system is supposed to be protected by a strong passphrase. There is no possibility for the server to check if this is the case. Many users do not use a strong passphrase or do not use any passphrase at all. If such a private key is stolen, an attacker can immediately use it to access the remote system.<br />
<br />
* There is no concept of validity. Users are not forced to regularly generate new SSH Key pairs and replace the old ones. Often the same key pair is used for many years and the users have no overview of how many systems they have stored their SSH Keys on.<br />
<br />
* SSH Keys can be restricted so they can only be used to execute specific commands on the server, or to log in from specified IP addresses. Most users do not do this.<br />
<br />
To fix these issues '''it is no longer possible to self-manage your SSH Keys by adding them to the ~/.ssh/authorized_keys file''' on bwUniCluster/bwForCluster.<br />
SSH Keys have to be managed through bwIDM/bwServces instead.<br />
Existing authorized_keys files are ignored.<br />
<br />
== Minimum requirements for SSH Keys ==<br />
<br />
Algorithms and Key sizes:<br />
<br />
* 2048 bits or more for RSA<br />
* 521 bits for ECDSA<br />
* 256 Bits (Default) for ED25519<br />
<br />
ECDSA-SK and ED25519-SK keys (for use with U2F Hardware Tokens) cannot be used yet.<br />
<br />
'''Please set a strong passphrase for your private keys.'''<br />
<br />
<br />
= Adding a new SSH Key =<br />
<br />
{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
* Newly added keys are valid for three months. After that, they are revoked and placed on a "revocation list" so that they cannot be reused.<br />
* Copy only the contents of your public ssh key file to bwIDM/bwServices. The file ends with <code>.pub</code> ( e.g. <code>~/.ssh/<filename>.pub</code>).<br />
|}<br />
<br />
'''SSH keys''' are generally managed via the '''My SSH Pubkeys''' menu entry on the registration pages for the clusters.<br />
Here you can add and revoke SSH keys. To add a ssh key, please follow these steps:<br />
<br />
1. '''Select the cluster''' for which you want to create a second factor:</br> &rarr; [https://login.bwidm.de/user/ssh-keys.xhtml '''bwUniCluster 2.0''']</br> &rarr; [https://bwservices.uni-heidelberg.de/user/ssh-keys.xhtml '''bwForCluster MLS&WISO''']<br />
[[File:BwIDM-twofa.png|center|600px|thumb|My SSH Pubkeys.]]<br />
<br />
3. Click the '''Add SSH Key''' or '''SSH Key Hochladen''' button.<br />
[[File:Bwunicluster 2.0 access ssh keys empty.png|center|400px|thumb|Add new SSH key.]]<br />
<br />
4. A new window will appear.<br />
Enter a name for the key and paste your SSH public key (file <code>~/.ssh/<filename>.pub</code>) into the box labelled "SSH Key:".<br />
Click on the button labelled '''Add''' or '''Hinzufügen'''.<br />
[[File:Ssh-key.png|center|600px|thumb|Add new SSH key.]]<br />
<br />
5. If everything worked fine your new key will show up in the user interface:<br />
[[File:Ssh-success.png|center|800px|thumb|New SSH key added.]]<br />
<br />
Once you have added SSH keys to the system, you can bind them to one or more services to use either for interactive logins ('''Interactive key''') or for automatic logins ('''Command key''').<br />
<br />
<br />
== Registering an Interactive Key ==<br />
<br />
{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
Interactive SSH Keys are not valid all the time, but only for one hour after the last 2-factor login.<br />
They have to be "unlocked" by entering the OTP and service password.<br />
|}<br />
<br />
'''Interactive Keys''' can be used to log into a system for interactive use.<br />
Perform the following steps to register an interactive key:<br />
<br />
1. [[Registration/SSH#Adding_a_new_SSH_Key|'''Add a new interactive SSH key''']] if you have not already done so.<br />
<br />
2. Select '''Registered services/Registrierte Dienste''' from the top menu and click '''Set SSH Key/SSH Key setzen''' for the cluster for which you want to use the SSH key.<br />
[[File:BwIDM-registered.png|center|600px|thumb|Select Cluster for which you want to use the SSH key.]]<br />
<br />
3. The upper block displays the SSH keys currently registered for the service.<br />
The bottom block displays all the public SSH keys associated with your account.<br />
Find the SSH key you want to use and click '''Add/Hinzufügen'''.<br />
[[File:Ssh-service-int.png|center|800px|thumb|Add SSH key to service.]]<br />
<br />
4. A new window appears.<br />
Select '''Interactive''' as the usage type, enter an optional comment and click '''Add/Hinzufügen'''.<br />
[[File:Ssh-int.png|center|600px|thumb|Add interactive SSH key to service.]]<br />
<br />
5. Your SSH key is now registered for interactive use with this service.<br />
[[File:Ssh-service.png|center|800px|thumb|SSH key is now registered for interactive use.]]<br />
<br />
<br />
== Registering a Command Key ==<br />
<br />
{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
SSH command keys are always valid and do not need to be unlocked with a 2-factor login.<br />
This makes these keys extremely valuable to a potential attacker and poses a security risk.<br />
Therefore, additional restrictions apply to these keys:<br />
* They must be limited to a single command to be executed.<br />
* They must be limited to a single IP address (e.g., the workflow server) or a small number of IP addresses (e.g., the institution's subnet).<br />
* They must be reviewed and approved by a cluster administrator before they can be used.<br />
* Validity is reduced to one month.<br />
|}<br />
<br />
'''Command Keys''' can be used for automatic workflows.<br />
Perform the following steps to register a "Command key":<br />
<br />
1. [[Registration/SSH#Adding_a_new_SSH_Key|'''Add a new "command SSH key"''']] if you have not already done so.<br />
<br />
<br />
2. Select '''Registered services/Registrierte Dienste''' from the top menu and click '''Set SSH Key/SSH Key setzen''' for the cluster for which you want to use the SSH key.<br />
[[File:BwIDM-registered.png|center|600px|thumb|Select Cluster for which you want to use the SSH key.]]<br />
<br />
3. The upper block displays the SSH keys currently registered for the service.<br />
The bottom block displays all the public SSH keys associated with your account.<br />
Find the SSH key you want to use and click '''Add/Hinzufügen'''.<br />
[[File:Ssh-service-com.png|center|800px|thumb|Add SSH key to service.]]<br />
<br />
4. A new window appears.<br />
Select '''Command''' as the usage type.<br />
Type the full command with the full path, including all parameters, in the '''Command''' text box.<br />
Specify a network address, list, or range in the '''From''' text field (see [https://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/sshd.8#from=_pattern-list_ man 8 sshd] for more info).<br />
Please also provide a comment to speed up the approval process.<br />
Click '''Add/Hinzufügen'''.<br />
{| class="wikitable"<br />
! | Example<br />
|-<br />
| If you want to register a command key to be able to transfer data automatically, please use the following string as in the '''Command''' text field (please verify the path on the cluster first):<br />
<pre><br />
/usr[/local]/bin/rrsync -ro / -rw /<br />
</pre><br />
|}<br />
[[File:Ssh-com.png|center|600px|thumb|Add interactive SSH key to service.]]<br />
<br />
5. After the key has been added, it will be marked as '''Pending''':<br />
You will receive an e-mail as soon as the key has been approved and can be used.<br />
[[File:Ssh-service.png|center|800px|thumb|SSH key is now registered for interactive use.]]<br />
<br />
<br />
== Revoke/Delete SSH Key ==<br />
<br />
{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
Revoked keys are locked and can no longer be used.<br />
|}<br />
<br />
'''SSH keys''' are generally managed via the '''My SSH Pubkeys''' menu entry on the registration pages for the clusters.<br />
Here you can add and revoke SSH keys. To revoke/delete a ssh key, please follow these steps:<br />
<br />
1. '''Select the cluster''' for which you want to create a second factor:</br> &rarr; [https://login.bwidm.de/user/ssh-keys.xhtml '''bwUniCluster 2.0''']</br> &rarr; [https://bwservices.uni-heidelberg.de/user/ssh-keys.xhtml '''bwForCluster MLS&WISO''']<br />
[[File:BwIDM-twofa.png|center|600px|thumb|My SSH Pubkeys.]]<br />
<br />
2. Click '''REVOKE/ZURÜCKZIEHEN''' next to the SSH key you want to revoke.<br />
[[File:Ssh-success.png|center|800px|thumb|Revoke SSH key.]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Registration/SSH&diff=10263Registration/SSH2022-03-30T13:27:20Z<p>S Siebler: /* Adding a new SSH Key */</p>
<hr />
<div>{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
This process is only necessary for the bwUniCluster and the bwForCluster MLS&WISO.<br />
On the other clusters, SSH keys can still be copied to the <code>authorized_keys</code> file.<br />
|}<br />
<br />
<br />
= Registering SSH Keys with your Cluster =<br />
<br />
{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
Interactive SSH Keys are not valid all the time, but only for one hour after the last 2-factor login.<br />
They have to be "unlocked" by entering the OTP and service password.<br />
|}<br />
<br />
'''SSH Keys''' are a mechanism for logging into a computer system without having to enter a password. Instead of authenticating yourself with something you know (a password), you prove your identity by showing the server something you have (a cryptographic key).<br />
<br />
The usual process is the following:<br />
<br />
* The user generates a pair of SSH Keys, a private key and a public key, on their local system. The private key never leaves the local system.<br />
<br />
* The user then logs into the remote system using the remote system password and adds the public key to a file called ~/.ssh/authorized_keys .<br />
<br />
* All following logins will no longer require the entry of the remote system password because the local system can prove to the remote system that it has a private key matching the public key on file.<br />
<br />
While SSH Keys have many advantages, the concept also has '''a number of issues''' which make it hard to handle them securely:<br />
<br />
* The private key on the local system is supposed to be protected by a strong passphrase. There is no possibility for the server to check if this is the case. Many users do not use a strong passphrase or do not use any passphrase at all. If such a private key is stolen, an attacker can immediately use it to access the remote system.<br />
<br />
* There is no concept of validity. Users are not forced to regularly generate new SSH Key pairs and replace the old ones. Often the same key pair is used for many years and the users have no overview of how many systems they have stored their SSH Keys on.<br />
<br />
* SSH Keys can be restricted so they can only be used to execute specific commands on the server, or to log in from specified IP addresses. Most users do not do this.<br />
<br />
To fix these issues '''it is no longer possible to self-manage your SSH Keys by adding them to the ~/.ssh/authorized_keys file''' on bwUniCluster/bwForCluster.<br />
SSH Keys have to be managed through bwIDM/bwServces instead.<br />
Existing authorized_keys files are ignored.<br />
<br />
== Minimum requirements for SSH Keys ==<br />
<br />
Algorithms and Key sizes:<br />
<br />
* 2048 bits or more for RSA<br />
* 521 bits for ECDSA<br />
* 256 Bits (Default) for ED25519<br />
<br />
ECDSA-SK and ED25519-SK keys (for use with U2F Hardware Tokens) cannot be used yet.<br />
<br />
'''Please set a strong passphrase for your private keys.'''<br />
<br />
<br />
= Adding a new SSH Key =<br />
<br />
{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
* Newly added keys are valid for three months. After that, they are revoked and placed on a "revocation list" so that they cannot be reused.<br />
* Copy only the contents of your public ssh key file to bwIDM/bwServices. The file ends with <code>.pub</code> ( e.g. <code>~/.ssh/<filename>.pub</code>).<br />
|}<br />
<br />
'''SSH keys''' are generally managed via the '''My SSH Pubkeys''' menu entry on the registration pages for the clusters.<br />
Here you can add and revoke SSH keys. To add a ssh key, please follow these steps:<br />
<br />
1. '''Select the cluster''' for which you want to create a second factor:</br> &rarr; [https://login.bwidm.de/user/ssh-keys.xhtml '''bwUniCluster 2.0''']</br> &rarr; [https://bwservices.uni-heidelberg.de/user/ssh-keys.xhtml '''bwForCluster MLS&WISO''']<br />
[[File:BwIDM-twofa.png|center|600px|thumb|My SSH Pubkeys.]]<br />
<br />
3. Click the '''Add SSH Key''' or '''SSH Key Hochladen''' button.<br />
[[File:Bwunicluster 2.0 access ssh keys empty.png|center|400px|thumb|Add new SSH key.]]<br />
<br />
4. A new window will appear.<br />
Enter a name for the key and paste your SSH public key (file <code>~/.ssh/<filename>.pub</code>) into the box labelled "SSH Key:".<br />
Click on the button labelled '''Add''' or '''Hinzufügen'''.<br />
[[File:Ssh-key.png|center|600px|thumb|Add new SSH key.]]<br />
<br />
5. If everything worked fine your new key will show up in the user interface:<br />
[[File:Ssh-success.png|center|800px|thumb|New SSH key added.]]<br />
<br />
Once you have added SSH keys to the system, you can bind them to one or more services to use either for interactive logins ('''Interactive key''') or for automatic logins ('''Command key''').<br />
<br />
<br />
== Registering an Interactive Key ==<br />
<br />
{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
Interactive SSH Keys are not valid all the time, but only for one hour after the last 2-factor login.<br />
They have to be "unlocked" by entering the OTP and service password.<br />
|}<br />
<br />
'''Interactive Keys''' can be used to log into a system for interactive use.<br />
Perform the following steps to register an interactive key:<br />
<br />
1. [[Registration/SSH#Adding_a_new_SSH_Key|'''Add a new interactive SSH key''']] if you have not already done so.<br />
<br />
2. Select '''Registered services/Registrierte Dienste''' from the top menu and click '''Set SSH Key/SSH Key setzen''' for the cluster for which you want to use the SSH key.<br />
[[File:BwIDM-registered.png|center|600px|thumb|Select Cluster for which you want to use the SSH key.]]<br />
<br />
3. The upper block displays the SSH keys currently registered for the service.<br />
The bottom block displays all the public SSH keys associated with your account.<br />
Find the SSH key you want to use and click '''Add/Hinzufügen'''.<br />
[[File:Ssh-service-int.png|center|800px|thumb|Add SSH key to service.]]<br />
<br />
4. A new window appears.<br />
Select '''Interactive''' as the usage type, enter an optional comment and click '''Add/Hinzufügen'''.<br />
[[File:Ssh-int.png|center|600px|thumb|Add interactive SSH key to service.]]<br />
<br />
5. Your SSH key is now registered for interactive use with this service.<br />
[[File:Ssh-service.png|center|800px|thumb|SSH key is now registered for interactive use.]]<br />
<br />
<br />
== Registering a Command Key ==<br />
<br />
{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
SSH command keys are always valid and do not need to be unlocked with a 2-factor login.<br />
This makes these keys extremely valuable to a potential attacker and poses a security risk.<br />
Therefore, additional restrictions apply to these keys:<br />
* They must be limited to a single command to be executed.<br />
* They must be limited to a single IP address (e.g., the workflow server) or a small number of IP addresses (e.g., the institution's subnet).<br />
* They must be reviewed and approved by a cluster administrator before they can be used.<br />
* Validity is reduced to one month.<br />
|}<br />
<br />
'''Command Keys''' can be used for automatic workflows.<br />
Perform the following steps to register a "Command key":<br />
<br />
1. [[Registration/SSH#Adding_a_new_SSH_Key|'''Add a new "command SSH key"''']] if you have not already done so.<br />
<br />
<br />
2. Select '''Registered services/Registrierte Dienste''' from the top menu and click '''Set SSH Key/SSH Key setzen''' for the cluster for which you want to use the SSH key.<br />
[[File:BwIDM-registered.png|center|600px|thumb|Select Cluster for which you want to use the SSH key.]]<br />
<br />
3. The upper block displays the SSH keys currently registered for the service.<br />
The bottom block displays all the public SSH keys associated with your account.<br />
Find the SSH key you want to use and click '''Add/Hinzufügen'''.<br />
[[File:Ssh-service-com.png|center|800px|thumb|Add SSH key to service.]]<br />
<br />
4. A new window appears.<br />
Select '''Command''' as the usage type.<br />
Type the full command with the full path, including all parameters, in the '''Command''' text box.<br />
Specify a network address, list, or range in the '''From''' text field (see [https://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/sshd.8#from=_pattern-list_ man 8 sshd] for more info).<br />
Please also provide a comment to speed up the approval process.<br />
Click '''Add/Hinzufügen'''.<br />
{| class="wikitable"<br />
! | Example<br />
|-<br />
| If you want to register a command key to be able to transfer data automatically, please use the following string as in the '''Command''' text field (please verify the path on the cluster first):<br />
<pre><br />
/usr[/local]/bin/rrsync -ro / -rw /<br />
</pre><br />
|}<br />
[[File:Ssh-com.png|center|600px|thumb|Add interactive SSH key to service.]]<br />
<br />
5. After the key has been added, it will be marked as '''Pending''':<br />
You will receive an e-mail as soon as the key has been approved and can be used.<br />
[[File:Ssh-service.png|center|800px|thumb|SSH key is now registered for interactive use.]]<br />
<br />
<br />
== Revoke/Delete SSH Key ==<br />
<br />
{|style="background:#deffee; width:100%;"<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
[[Image:Attention.svg|center|25px]]<br />
|style="padding:5px; background:#cef2e0; text-align:left"|<br />
Revoked keys are locked and can no longer be used.<br />
|}<br />
<br />
'''SSH keys''' are generally managed via the '''My SSH Pubkeys''' menu entry on the registration pages for the clusters.<br />
Here you can add and revoke SSH keys. To revoke/delete a ssh key, please follow these steps:<br />
<br />
1. '''Select the cluster''' for which you want to create a second factor:</br> &rarr; [https://login.bwidm.de/user/ssh-keys.xhtml '''bwUniCluster 2.0''']</br> &rarr; [https://login.bwidm.de/user/ssh-keys.xhtml '''bwForCluster MLS&WISO''']<br />
[[File:BwIDM-twofa.png|center|600px|thumb|My SSH Pubkeys.]]<br />
<br />
2. Click '''REVOKE/ZURÜCKZIEHEN''' next to the SSH key you want to revoke.<br />
[[File:Ssh-success.png|center|800px|thumb|Revoke SSH key.]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=File:BwServices_my_tokens.png&diff=8874File:BwServices my tokens.png2021-06-19T11:11:24Z<p>S Siebler: </p>
<hr />
<div></div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Category:BwForCluster_MLS%26WISO_Production&diff=8835Category:BwForCluster MLS&WISO Production2021-06-09T14:09:43Z<p>S Siebler: add security notice</p>
<hr />
<div>The production part of bwForCluster MLS&WISO is a high-performance compute resource with high speed interconnect. It is intended for compute activities related to research in Structural and Systems Biology, Medical Science, Soft Matter, and Computational Humanities. The hardware is located partly in Mannheim and partly in Heidelberg. Both sites are interconnected by a long-range, low-latency, high bandwidth, Infiniband link effectively forming one single cluster. The system is jointly operated by the Computing Center of the University of Mannheim ([https://www.uni-mannheim.de/it/ UNIT]) and the Computing Center of Heidelberg University ([http://www.urz.uni-heidelberg.de/ URZ]).<br />
<br />
<div style="text-align:center;">Submit your planned compute activities to have them assigned to appropriate bwHPC cluster resources.<br />See [[BwForCluster_User_Access|bwForCluster Registration]] for details on the procedure.</div><br />
<br />
<!-- not centered without a table due to broken kit theme --><br />
{| style="margin: 1em auto 1em auto;"<br />
|[[File:Bwforcluster-prod.png|center|600px|thumb|alt=bwForCluster MLS&WISO Production | ]]<br />
|}<br />
<br />
<!-- One column table --><br />
{| style="width: 100%; margin:4px 0 0 0; background:none; border-spacing: 0px;"<br />
| style="width:100%; border:1px solid #BBBBBB; background:#fff5fa; vertical-align:top; color:#000;" |<br />
{| style="width:100%; vertical-align:top; border:0px solid #BBBBBB; padding:4px;" |<br />
|-<br />
|{{Red}}| New security measures<br />
|-<br />
|<br />
On 18.06.2021 at 10 AM the following changes to the security policies will take effect:<br />
<br />
* For authentication, the use of a second factor (2-factor authentication) in addition to the service password will be mandatory. [[BwForCluster_MLS%26WISO_Production_2FA_tokens|You can find the user documentation for this function here]].<br />
<br />
* The use of SSH keys will be possible again. However, these can no longer be managed via the authorized_keys files, but only centrally via bwServices. [[BwForCluster_MLS%26WISO_Production_SSH_keys|You can find the user documentation for this function here]].<br />
<br />
The following restrictions still apply:<br />
<br />
* Access is limited to IP addresses from within the campus networks of the respective home institutions of our current users. If you are outside of one of these networks (e.g. in your home office), a VPN connection to your home institution has to be established first (see e.g. [https://www.urz.uni-heidelberg.de/de/vpn] for Heidelberg University).<br />
|}<br />
|}<br />
<br />
<br />
{| style="width: 100%; margin:4px 0 0 0; background:none; border-spacing: 0px;"<br />
| style="width:50%; border:1px solid #BBBBBB; background:#f5fffa; vertical-align:top; color:#000;" |<br />
{| style="width:100%; vertical-align:top; border:0px solid #BBBBBB; padding:4px;" |<br />
|-<br />
|{{Green}}|Access<br />
|-<br />
|<br />
* [[BwForCluster_User_Access|bwForCluster Registration]] Procedure and [[bwForCluster_MLS&WISO_Production_Login|Login]] nodes<br />
* [[bwForCluster_MLS&WISO_Production_Contact|Contact and Support]]<br />
|-<br />
| {{Green}} | Software<br />
|-<br />
|<br />
* [[Software Modules]] <br />
* Summary via [http://cis-hpc.uni-konstanz.de Cluster Information System]<br />
|-<br />
|{{Green}}| Hardware<br />
|-<br />
|<br />
* [[bwForCluster_MLS&WISO_Production_Hardware|Hardware and Architecture]] <br />
* [[bwForCluster_MLS&WISO_Production_Filesystems|File Systems]]<br />
<br />
|}<br />
<br />
| style="padding:2px;" |<br />
| style="width:50%; border:1px solid #BBBBBB; background:#f5faff; vertical-align:top; color:#000;" |<br />
{| style="width:100%; vertical-align:top; border:0px solid #BBBBBB; padding:4px;" |<br />
|-<br />
|{{Blue}}| Batch/Compute Jobs<br />
|-<br />
| <br />
* [[bwForCluster_MLS&WISO_Production_Slurm|Slurm on bwForCluster MLS&WISO Production]]<br />
|-<br />
|{{Blue}}|[[bwHPC Best Practices Repository]]<br />
|-<br />
| <br />
* [[Compiler]]<br />
* [[Debugger]]<br />
* [[Numerical Libraries]]<br />
* [[Parallel Programming]]<br />
|-<br />
|{{Blue}}| Cluster Funding<br />
|-<br />
| <br />
* [[bwForCluster_MLS&WISO_Production_Acknowledgement|Acknowledgement]] of work performed on the cluster<br />
|}<br />
|}<br />
<br />
<br><br />
-----<br />
<br><br />
<br><br />
[[Category:bwHPC_infrastructure]][[Category:bwHPC_Cluster]][[Category:bwForCluster]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Category:BwForCluster_MLS%26WISO_Production_SSH_keys&diff=8832Category:BwForCluster MLS&WISO Production SSH keys2021-06-09T14:01:52Z<p>S Siebler: S Siebler moved page Category:BwForCluster MLS&WISO Production SSH keys to BwForCluster MLS&WISO Production SSH keys</p>
<hr />
<div>#REDIRECT [[BwForCluster MLS&WISO Production SSH keys]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=BwForCluster_User_Access&diff=8828BwForCluster User Access2021-06-09T13:45:59Z<p>S Siebler: update 2FA for MLS&WISO</p>
<hr />
<div>Granting user access to a bwForCluster requires 3 steps:<br />
<br />
# [[File:Zas assignment icon.svg|25px|]] Become part of an ''rechenvorhaben (RV)'' either by joining as a coworker or creating a new one <br />
# [[File:bwfor entitlement icon.svg|25px|]] Permission from your university to use a bwForCluster called [[BwForCluster_Entitlement| bwForCluster entitlement]] <br />
# [[#Personal registration at bwForCluster | Personal registration at the cluster site ]] based on approved ''RV'' [[File:Zas assignment icon.svg|25px|]] and issued bwForCluster entitlement [[File:bwfor entitlement icon.svg|25px|]].<br />
<br />
<br />
{| style="width: 100%; border-spacing: 5px;"<br />
| style="text-align:center; color:#000;vertical-align:middle;font-size:75%;" |[[File:Bwforreg.svg|center|border|500px|]] <br />
|-<br />
| style="text-align:center; color:#000;vertical-align:middle;" |<br />
|}<br />
<br />
<br />
<br><br />
Step 1 and 2 can be done at the same time. When both are finished, you can do step 3. Which cluster you will get access to depends on your research area and is decided in step 1.<br />
<br />
<br />
= <b> ''RV'' registration at ''ZAS'' </b>=<br />
<br />
Typically an RV is registered by the leader or a senior scientist of a research group/collaboration. <br />
<br />
Any amount of co-workers can then join your RV to do work using the cluster.<br />
<br />
== Register a new "RV" ==<br />
<br />
In a RV, you will be asked to shortly describe your group's compute activities and the resources you need.<br />
<br />
If you register your own RV, you will be:<br />
# held accountable for the co-workers in the RV<br />
# asked to provide information for the two reports required by the DFG for their funding of bwFor clusters<br />
# likely asked for a contribution to a future DFG grant proposal for a new bwFor cluster in your area of research ("wissenschaftliches Beiblatt")<br />
<br />
Please follow the steps at [[bwForCluster RV registration]]<br />
<br />
== Become Coworker of an "RV"==<br />
<br />
Your advisor (the "RV" responsible") will provide you with the following data on the RV:<br />
* acronym<br />
* password<br />
<br />
To become coworker of an ''RV'', please login at<br />
* https://www.bwhpc-c5.de/en/ZAS/bwforcluster_collaboration.php<br />
and provide acronym and password. You will be assigned to the 'RV' as a member.<br />
<br />
After submitting the request you will receive an email from ''ZAS'' about the further steps (i.e. [[#Personal registration at bwForCluster | personal registration at assigned bwForCluster]]). <br />
The RV owner and any managers will be notified automatically. <br />
You can see your RV memberships at https://www.bwhpc-c5.de/en/ZAS/info_rv.php<br />
<br><br />
<br />
= <b> Permission of Your University ("bwForCluster entitlement") </b> =<br />
<br />
Your own high school or university has to grant you permission to use a bwForCluster. <br />
<br />
Getting permission from your university to calculate on bwForClusters is independent of an RV and can be done before or while getting an RV. If you are only creating an RV for your research group but do '''not''' plan to use the cluster yourself, you do not need to do this step. <br />
<br />
Each university has their own procedure. <br />
<br />
Please continue to the next step on this page and log in to a registration server. This will show you the list of your entitlements. <br />
If the list contains <pre> http://bwidm.de/entitlement/bwForCluster </pre> you already have the entitlement.<br />
<br />
The page [[bwForCluster Entitlement]] contains a list of participating universities and links to instructions on how to get an bwForCluster entitlement at each of them.<br />
<br />
= <b> Personal registration at a bwForCluster - account creation</b> = <br />
<br />
<b>Prerequisites for successful account creation:</b><br />
* [[BwForCluster_User_Access#RV_registration_at_ZAS|Membership in an RV (belonging to the bwForCluster you plan to join)]].<br />
* [[BwForCluster_User_Access#Permission_of_Your_University_.28.22bwForCluster_entitlement.22.29|bwForCluster entitlement (assigned by your university)]].<br />
<br />
Once you have registered your own RV (''rechenvorhaben'')<br />
or a membership in an RV, you will receive<br />
an email with a website to create an account for yourself<br />
on that cluster. This email will send you to one of the following websites:<br />
<br />
Available bwForCluster registration servers (service providers):<br />
{| style="border:3px solid darkgray; margin: 1em auto 1em auto;" width="72%"<br />
|- <br />
!scope="row" {{Darkgray}} | Cluster topic and location<br />
!scope="row" {{Darkgray}} | Registration server (for account creation)<br />
|-<br />
| bwForCluster JUSTUS 2 Ulm for Computational Chemistry and Quantum Sciences<br />
| https://login.bwidm.de <br />
|-<br />
| bwForCluster MLS&WISO (Production and Development)<br />
| https://bwservices.uni-heidelberg.de<br />
|-<br />
| bwForCluster NEMO Freiburg<br />
| https://bwservices.uni-freiburg.de<br />
|-<br />
| bwForCluster BinAC Tübingen<br />
| https://bwservices.uni-tuebingen.de<br />
|}<br />
<br />
In this chapter, a user account will be created at the cluster based on your personal credentials. <br />
<br />
After having completed chapters 1 and 2 (RV approval and bwForCluster entitlement) please visit the<br />
<br />
* bwForCluster ''service provider'' registration website (see table above or email after RV approval):<br />
*# Select your home organization from the list of organizations and click '''Proceed'''.<br />
*# You will be redirected to the ''Identity Provider'' of your home organization.<br />
*# Enter your home-organizational user ID (might be user name, email, ...) and password and click '''Login''' or '''Anmelden'''.<br />
*# When doing this for the first time you need to accept that your personal data is transferred to the ''service provider''.<br />
*# You will be redirected back to the cluster registration website.<br />
*# '''JUSTUS 2 only''': This step is required before registration for JUSTUS 2: To improve security a 2-factor authentication mechanism (2FA) is being enforced. You can manage your 2FA tokens by clicking on [https://login.bwidm.de/user/twofa.xhtml this link] or on '''My Tokens''' in the main menu of the JUSTUS 2 registration website. The instructions for registering a new 2FA token can be found on the following page: [[BwForCluster User Access/2FA Tokens]]. Please create at least one 2FA token before proceeding with JUSTUS 2 registration.<br />
*# '''MLS&WISO only''': This step is required before registration for MLS&WISO: To improve security a 2-factor authentication mechanism (2FA) is being enforced. You can manage your 2FA tokens by clicking on [https://bwservices.uni-heidelberg.de/user/twofa.xhtml this link] or on '''My Tokens''' in the main menu of the bwServices registration website. The instructions for registering a new 2FA token can be found on the following page: [[BwForCluster MLS&WISO Production 2FA tokens]]. Please create at least one 2FA token before proceeding with MLS&WISO registration.<br />
*# Select '''Service description''' within the box of your '''designated cluster'''. If the cluster is not visible, the reasons are either a missing entitlement or you are not member in an RV assigned to <br />
that cluster - see prerequisites at the beginning of this chapter.<br />
*# Click on the '''Register''' link below the service description to register for this cluster.<br />
*# Make sure all requirements are met by checking the '''Requirements''' box at the top. If the requirements are not met you might be able to correct the issue by following the instructions. In all other cases please [http://www.support.bwhpc-c5.de open a ticket at the bwSupport Portal]. [[File:BwUniCluster 2.0 access login bwidm registration requirements.png|center|border|]]<br />
*# Read and accept the terms and conditions of use ('''[v] I have read and accepted the terms of use''') and click on button '''Register'''. When requirements are missing, i.e. a missing second factor for authentication, you may need to correct that before being able to click on button "Register".<br />
*# Click on '''Set Service Password''' and set a password for the cluster. '''Note: Setting a SERVICE password is MANDATORY for access to any bwForCluster. Using the password of your home organization is not accepted anymore.'''<br />
*# Finally you will receive an email with instructions how to login to the cluster. Please wait at least 15 minutes before trying to login. More details about cluster login can be found in the next chapter. '''Note: Carefully read the email send by the registration server after account registration.'''<br />
*# '''Note:''' You can return to the registration website at any time, in order to review your registration details, change/reset your service password or deregister from the service by yourself.<br />
<br />
= <b> Login to bwForCluster </b> = <br />
<br />
Personalized details about how to login to the cluster are included<br />
in an email send after registration at the bwForCluster service provider.<br />
<br />
General instructions for the bwForCluster login can be found here:<br />
{| style="border:3px solid darkgray; margin: 1em auto 1em auto;" width="73%"<br />
|- <br />
!scope="row" {{Darkgray}} | Cluster topic and location<br />
!scope="row" {{Darkgray}} | Login instructions<br />
|-<br />
| bwForCluster Chemistry JUSTUS 2 Ulm for Computational Chemistry and Quantum Sciences<br />
| [[BwForCluster_JUSTUS2_Login|bwForCluster JUSTUS 2 Login]]<br />
|-<br />
| bwForCluster MLS&WISO Production<br />
| [[BwForCluster_MLS&WISO_Production_Login|bwForCluster MLS&WISO Production Login]]<br />
|-<br />
| bwForCluster MLS&WISO Development<br />
| [[BwForCluster_MLS&WISO_Development_Login|bwForCluster MLS&WISO Development Login]]<br />
|-<br />
| bwForCluster NEMO Freiburg<br />
| [[bwForCluster NEMO Login]] <br />
|-<br />
| bwForCluster BinAC Tübingen<br />
| [[bwForCluster BinAC Login]] <br />
<br />
|}<br />
<br />
<br><br />
<br />
= <b> Costs and Funding </b> =<br />
The usage of bwForCluster is free of charge. bwForClusters are customized to the requirements of particular research areas. <br />
<br />
bwForClusters are financed by the DFG (German Research Foundation) and by the Ministry of Science, Research and Arts of Baden-Württemberg based on scientifc grant proposal (compare proposals guidelines as per Art. 91b GG).<br />
<br />
----<br />
[[Category:Access|bwForCluster]][[Category:bwForCluster_Chemistry]][[Category:bwForCluster_MLS&WISO_Production]][[Category:bwForCluster_MLS&WISO_Development]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Category:BwForCluster_MLS%26WISO_Production_2FA_tokens&diff=8826Category:BwForCluster MLS&WISO Production 2FA tokens2021-06-09T13:44:36Z<p>S Siebler: S Siebler moved page Category:BwForCluster MLS&WISO Production 2FA tokens to BwForCluster MLS&WISO Production 2FA tokens</p>
<hr />
<div>#REDIRECT [[BwForCluster MLS&WISO Production 2FA tokens]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Category:BwForCluster_MLS%26WISO_Production/SSH_keys&diff=8824Category:BwForCluster MLS&WISO Production/SSH keys2021-06-09T13:37:02Z<p>S Siebler: S Siebler moved page Category:BwForCluster MLS&WISO Production/SSH keys to Category:BwForCluster MLS&WISO Production SSH keys</p>
<hr />
<div>#REDIRECT [[:Category:BwForCluster MLS&WISO Production SSH keys]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Category:BwForCluster_MLS%26WISO_Production/2FA_tokens&diff=8822Category:BwForCluster MLS&WISO Production/2FA tokens2021-06-09T13:35:05Z<p>S Siebler: S Siebler moved page Category:BwForCluster MLS&WISO Production/2FA tokens to Category:BwForCluster MLS&WISO Production 2FA tokens</p>
<hr />
<div>#REDIRECT [[:Category:BwForCluster MLS&WISO Production 2FA tokens]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=8529Sds-hd CIFS2021-04-16T09:04:59Z<p>S Siebler: /* Prerequisites */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
The SMB connection has to be established at least with Protocolversion SMB2.02, which is available since Windows Vista or OSX 10.7, and a [https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level NTLMv2 Authentication Level] of "Send NTLMv2 responses only"<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!--<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
--><br />
<br><br />
<br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
'''Important''' To use SMB Protocol you need a OSX Version 10.7 or newer!<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!-- path outdated:<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
--><br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0,mfsymlinks //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,mfsymlinks,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_idmapping&diff=8264Sds-hd idmapping2021-02-03T11:58:13Z<p>S Siebler: /* Example configuration of SSSD */</p>
<hr />
<div>== SDS@hd ID-Mapping ==<br />
<br />
ID-Mapping allows you to map the uidNumbers/gidNumbers of SDS@hd accounts to more descriptive usernames. <br />
<br />
If ID-Mapping is not or not correct configured, the ownerships and permissions of files/folders you see in the filesystem, will be incorrect. This could be confusing for users, but nevertheless the permission checking is done correctly on serversite.<br />
<br />
Because [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/configuring_domains SSSD] is one of the standard tools and it supports more than one ldap/identity provider on a system, we are showing here an example configuration for this tool.<br />
<br />
But of course you can use any other mechanism/tool to do the LDAP queries for ID Mapping if you want.<br />
The connection to SDS@hd LDAP Server is authenticated with the kerberos keytab of your machine. You can use any tool which supports GSSAPI with kerberos for authentication with the following parameters:<br />
* uri: ldap://bwservices.uni-heidelberg.de<br />
* search_base: dc=bwservices,dc=uni-heidelberg.de,dc=de<br />
* sasl mech: GSSAPI Authentication<br />
* krb5 Realm: BWSERVICES.UNI-HEIDELBERG.DE<br />
<br />
<br />
If you don't need a [[Sds-hd_nfs#Prerequisites|machine keytab]], but you still need ID Mapping (e.g. for CIFS Mounts on linux), you can use your Servicepassword to [[Sds-hd_nfs#automated_kerberos_tickets|create a user keytab]] for LDAP authentication.<br />
<br />
=== Example configuration of SSSD ===<br />
<br />
The authentication to SDS@hd is done via kerberos. <br />
<br />
If you have setup a working [[Sds-hd_kerberos|kerberos environment]], you have to install the needed packages for kerberos and SSSD, e.g:<br />
<br />
* RedHat/CentOS:<br />
<pre>$ yum install sssd-client sssd-krb5 sssd-ldap</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install sssd sssd-krb5 sssd-ldap sssd-tools libnss-sss libsasl2-modules-gssapi-mit</pre><br />
<br />
If not existing, create a SSSD configuration file (/etc/sssd/sssd.conf) like this:<br />
<pre><br />
[sssd]<br />
domains = BWSERVICESAD<br />
config_file_version = 2<br />
services = nss<br />
<br />
[domain/BWSERVICESAD]<br />
id_provider = ldap<br />
ldap_uri = ldap://bwservices.uni-heidelberg.de<br />
ldap_search_base = dc=bwservices,dc=uni-heidelberg,dc=de<br />
ldap_referrals = false<br />
<br />
ldap_schema = ad<br />
ldap_id_mapping = true<br />
min_id = 2000<br />
<br />
ldap_sasl_mech = GSSAPI<br />
krb5_realm = BWSERVICES.UNI-HEIDELBERG.DE<br />
ldap_sasl_authid = <HOSTNAME$ or Username><br />
ldap_krb5_keytab = <path_to_your_keytab><br />
krb5_server = bwservices.uni-heidelberg.de<br />
ldap_sasl_canonicalize = false<br />
krb5_canonicalize = false<br />
<br />
use_fully_qualified_names = true<br />
full_name_format = %3$s\%1$s<br />
<br />
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))) <br />
enumerate = false<br />
</pre><br />
<br />
<span style="color:red">Attention: </span> '''Don't forget to change "ldap_sasl_authid" to the Hostname/Username corresponding to your keytab file and the path to your keytab (e.g. /etc/krb5.keytab)!'''<br />
<br />
If you are allready using another service for authentication or name resolution on the machine, an additional domain block can be set up for this and has to be added to the line "domains".<br />
<br />
To enable SSSD for ID-Mapping in your system the lines "passwd" and "group" in file "/etc/nsswitch.conf" have to be extended by "sss", e.g.:<br />
<pre><br />
$ cat /etc/nsswitch.conf<br />
[...]<br />
passwd: compat sss<br />
group: compat sss<br />
</pre><br />
<br />
'''Note''': If you are using sssd you should not use "nscd" in parallel! Otherwise this could lead to undefined behaviour due to double caching passwd and group entries.<br />
<br />
After configuring SSSD you should enable and restart the service, e.g.:<br />
<pre><br />
$ systemctl enable sssd.service <br />
$ systemctl restart sssd.service<br />
</pre><br />
<br />
[[Category:Sds-hd|NFS|Kerberos]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=7139Sds-hd CIFS2020-09-23T16:19:26Z<p>S Siebler: /* Using SMB/CIFS for Mac OS client */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
The SMB connection has to be established at least with Protocolversion SMB2.02, which is available since Windows Vista or OSX 10.7<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!--<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
--><br />
<br><br />
<br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
'''Important''' To use SMB Protocol you need a OSX Version 10.7 or newer!<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!-- path outdated:<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
--><br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0,mfsymlinks //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,mfsymlinks,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=7138Sds-hd CIFS2020-09-23T16:17:52Z<p>S Siebler: /* Prerequisites */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
The SMB connection has to be established at least with Protocolversion SMB2.02, which is available since Windows Vista or OSX 10.7<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!--<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
--><br />
<br><br />
<br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!-- path outdated:<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
--><br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0,mfsymlinks //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,mfsymlinks,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_kerberos&diff=7128Sds-hd kerberos2020-09-16T18:34:30Z<p>S Siebler: /* kerberos environment for SDS@hd */</p>
<hr />
<div>== kerberos environment for SDS@hd ==<br />
<br />
<br />
* For Kerberos authentication to work, a correctly synchronized system time must be set on each nfs client (e.g. via [https://linux.die.net/man/8/ntpdate ntpdate] ntp01.urz.uni-heidelberg.de or [https://chrony.tuxfamily.org chrony])<br />
<br />
The following parameters of kerberos tickets are set on server side: <br />
* max. Lifetime of a Serviceticket: 10 hours<br />
* max. Lifetime of a Userticket: 24 hours<br />
* max. Renewaltime for Usertickets: 10 days<br />
<br />
The properties (e.g. lifetimes, encryption, ...) of the kerberos tickets can be changed on client site with different kinit parameters (see manpages of kinit) or via ''/etc/krb5.conf''.<br />
<br />
First you have to install kerberos packages in your system to provide a working kerberos environment. The exact names of the packages depending on you linux distribution (see examples below).<br />
<br />
''Example RedHat/CentOS''<br />
<pre>yum install krb5-workstation</pre><br />
<br />
''Example debian/ubuntu''<br />
<pre>apt install krb5-user</pre><br />
On ubuntu server: nfs-kernel-server<br />
<br />
<br />
After installing the packages you have to use the following kerberos parameters for connecting to SDS@hd:<br />
<br />
* Default Realm = BWSERVICES.UNI-HEIDELBERG.DE<br />
* KDC = bwservices.uni-heidelberg.de<br />
<br />
So your kerberos configuration file (/etc/krb5.conf) should contain the following entries:<br />
<pre><br />
[libdefaults]<br />
default_realm = BWSERVICES.UNI-HEIDELBERG.DE<br />
<br />
[realms]<br />
BWSERVICES.UNI-HEIDELBERG.DE= {<br />
kdc = bwservices.uni-heidelberg.de<br />
admin_server = bwservices.uni-heidelberg.de<br />
}<br />
[domain_realm]<br />
.uni-heidelberg.de = BWSERVICES.UNI-HEIDELBERG.DE<br />
uni-heidelberg.de = BWSERVICES.UNI-HEIDELBERG.DE<br />
</pre><br />
<br />
The keytab file of the machine, which you get from the [mailto:sds-hd-support@urz.uni-heidelberg.de SDS@hd Team], has to be stored as ''/etc/krb5.keytab'' in the system.<br />
<br />
Because of caching issue with the kerberos ticket cache, you have to disable gssproxy service:<br />
<pre><br />
systemctl stop gssproxy.service<br />
systemctl mask gssproxy.service<br />
</pre><br />
[[Category:Sds-hd|NFS|Kerberos]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_nfs&diff=6572Sds-hd nfs2020-06-23T11:45:41Z<p>S Siebler: /* AutoFS Setup */</p>
<hr />
<div>= <b> Prerequisites </b> =<br />
<br />
* '''Attention:''' To access data served by SDS@hd, You need a '''''Service Password'''''. See details [[Sds-hd_user_access]].<br />
<br />
* Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network]. This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
* The access via nfs protocol is machine-based, which means '''new nfs-Clients have to be registered''' on SDS@hd. During this registration each machine gets a keytab file, which allows mounting SDS@hd.<br />
<br />
* Currently you have to [mailto:sds-hd-support@urz.uni-heidelberg.de?subject=SDS@hd%20nfs-Client%20Registration send an email] for Clientregistration to SDS@hd Team with the following information:<br />
** hostname of the new nfs-Client<br />
** IP address<br />
** short description<br />
** location<br />
** acronym of the Speichervorhaben which should be available on this machine<br />
<br />
= <b> Using NFSv4 for UNIX client </b> = <br />
<br />
The authentication for data access via NFSv4 is performed using Kerberostickets. This requires a functioning Kerberos environment on the client!<br />
<br />
{{:Sds-hd_kerberos}}<br />
<br />
After configuring kerberos, you have to install nfs packages in your system, and enable kerberized NFSv4. The exact names of the packages depending on you linux distribution (see examples below).<br />
<br />
''Example RedHat/CentOS''<br />
<pre><br />
> yum install nfs-utils nfs4-acl-tools<br />
<br />
/etc/sysconfig/nfs:<br />
NEED_IDMAPD=yes<br />
NEED_GSSD=yes<br />
</pre><br />
<br />
''Example debian/ubuntu''<br />
<pre><br />
> apt install nfs-common nfs4-acl-tools nfs-server<br />
<br />
/etc/default/nfs-common:<br />
NEED_IDMAPD=yes<br />
NEED_GSSD=yes<br />
</pre><br />
On ubuntu server: nfs-kernel-server<br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
To enable the ID-Mapping for NFSv4 mounts change the file ''/etc/idmapd.conf'' with the following lines:<br />
<pre><br />
in /etc/idmapd.conf:<br />
[General]<br />
Domain = urz.uni-heidelberg.de<br />
Local-Realms = BWSERVICES.UNI-HEIDELBERG.DE<br />
</pre><br />
<br />
== mount a nfs share ==<br />
The usual restrictions for mounting drives under Linux apply. Usually this can only be done by the superuser "root". For detailed information, please contact the system administrator of your system.<br />
<br />
After successfull configuration (s. 2.1) you can mount your SDS@hd share with the following commands:<br />
<pre><br />
> mkdir <mountpoint><br />
> mount -t nfs4 -o sec=krb5,vers=4.0 lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint><br />
</pre><br />
<br />
To enable the mounting after a restart, you have to add the following line to the file "/etc/fstab"<br />
<pre><br />
lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint> nfs4 sec=krb5,vers=4.0 0 0<br />
</pre><br />
<br />
=== AutoFS Setup ===<br />
<br />
Instead of the fstab-entry you can also use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
sds-hd -fstype=nfs4,rw,sec=krb5,vers=4.0,nosuid,nodev lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02<br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file, e.g.:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the shares.<br />
<br />
== access your data ==<br />
'''Attention!''' The access can not be done as root user, because root uses the Kerberosticket of the machine, which does not have data access! <br />
<br />
To access your data on SDS@hd you have to fetch a valid kerberos ticket with your SDS@hd user and Servicepassword:<br />
<pre><br />
> kinit hd_xy123<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
</pre><br />
You can check afterwards your kerberos ticket with:<br />
<pre><br />
> klist<br />
Ticket cache: FILE:/tmp/krb5cc_1000<br />
Default principal: hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE<br />
<br />
Valid starting Expires Service principal<br />
20.09.2017 04:00:01 21.09.2017 04:00:01 krbtgt/BWSERVICES.UNI-HEIDELBERG.DE@BWSERVICES.UNI-HEIDELBERG.DE<br />
renew until 29.09.2017 13:38:49<br />
</pre><br />
<br />
Afterwards you should be able to access the mountpoint, which contain all Speichervorhaben exported to your machine:<br />
<pre><br />
> ls <mountpoint><br />
sd16j007 sd17c010 sd17d005<br />
</pre><br />
<br />
== renew a kerberos ticket ==<br />
Because a kerberos ticket has a limited lifetime (default: 10 hours, maximum 24 hours) for security reasons, you have to renew your ticket before it expires to prevent access loss.<br />
<pre><br />
> kinit -R<br />
</pre><br />
<br />
This renewal could only be done for maximum time of 10 Days and as long as the current kerberos ticket is still valid. For renewal of an expired ticket, you have to use again your Servicepassword.<br />
<br />
== destroy kerberos ticket ==<br />
Even if kerberos tickets are only valid for a limited period of time, a ticket should be destroyed as soon as access is no longer needed to prevent misuse on multi-user systems:<br />
<pre>kdestroy</pre><br />
<br />
== automated kerberos tickets ==<br />
<span style="color:red"><strong>'''Attention!''' Keep this generated Keytab safe and use it only in trusted environments!</strong></span><br />
<br />
If your workflow needs a permanent access to SDS@hd for longer than 10 Days, you can use '''ktutil''' to encrypt your Service Password into a keytab file:<br />
<br />
''interactive way:''<br />
<pre><br />
ktutil<br />
ktutil: addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e rc4-hmac<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE:<br />
ktutil: addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e aes256-cts<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE:<br />
ktutil: wkt xy123.keytab<br />
ktuitl: quit<br />
</pre><br />
<br />
''non-interactive way:''<br />
<pre><br />
echo -e "addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e rc4-hmac\n<your_servicepasword>\n<br />
addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e aes256-cts\n<your_servicepasword>\nwkt xy123.keytab" | ktutil<br />
</pre><br />
<br />
With this keytab, you can fetch a kerberos ticket without an interactive password:<br />
<pre><br />
kinit -k -t xy123.keytab hd_xy123 <br />
</pre><br />
<br><br />
<br />
[[Category:Sds-hd|NFS|Kerberos]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_nfs&diff=6571Sds-hd nfs2020-06-23T11:45:17Z<p>S Siebler: /* mount a nfs share */</p>
<hr />
<div>= <b> Prerequisites </b> =<br />
<br />
* '''Attention:''' To access data served by SDS@hd, You need a '''''Service Password'''''. See details [[Sds-hd_user_access]].<br />
<br />
* Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network]. This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
* The access via nfs protocol is machine-based, which means '''new nfs-Clients have to be registered''' on SDS@hd. During this registration each machine gets a keytab file, which allows mounting SDS@hd.<br />
<br />
* Currently you have to [mailto:sds-hd-support@urz.uni-heidelberg.de?subject=SDS@hd%20nfs-Client%20Registration send an email] for Clientregistration to SDS@hd Team with the following information:<br />
** hostname of the new nfs-Client<br />
** IP address<br />
** short description<br />
** location<br />
** acronym of the Speichervorhaben which should be available on this machine<br />
<br />
= <b> Using NFSv4 for UNIX client </b> = <br />
<br />
The authentication for data access via NFSv4 is performed using Kerberostickets. This requires a functioning Kerberos environment on the client!<br />
<br />
{{:Sds-hd_kerberos}}<br />
<br />
After configuring kerberos, you have to install nfs packages in your system, and enable kerberized NFSv4. The exact names of the packages depending on you linux distribution (see examples below).<br />
<br />
''Example RedHat/CentOS''<br />
<pre><br />
> yum install nfs-utils nfs4-acl-tools<br />
<br />
/etc/sysconfig/nfs:<br />
NEED_IDMAPD=yes<br />
NEED_GSSD=yes<br />
</pre><br />
<br />
''Example debian/ubuntu''<br />
<pre><br />
> apt install nfs-common nfs4-acl-tools nfs-server<br />
<br />
/etc/default/nfs-common:<br />
NEED_IDMAPD=yes<br />
NEED_GSSD=yes<br />
</pre><br />
On ubuntu server: nfs-kernel-server<br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
To enable the ID-Mapping for NFSv4 mounts change the file ''/etc/idmapd.conf'' with the following lines:<br />
<pre><br />
in /etc/idmapd.conf:<br />
[General]<br />
Domain = urz.uni-heidelberg.de<br />
Local-Realms = BWSERVICES.UNI-HEIDELBERG.DE<br />
</pre><br />
<br />
== mount a nfs share ==<br />
The usual restrictions for mounting drives under Linux apply. Usually this can only be done by the superuser "root". For detailed information, please contact the system administrator of your system.<br />
<br />
After successfull configuration (s. 2.1) you can mount your SDS@hd share with the following commands:<br />
<pre><br />
> mkdir <mountpoint><br />
> mount -t nfs4 -o sec=krb5,vers=4.0 lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint><br />
</pre><br />
<br />
To enable the mounting after a restart, you have to add the following line to the file "/etc/fstab"<br />
<pre><br />
lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint> nfs4 sec=krb5,vers=4.0 0 0<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Instead of the fstab-entry you can also use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
sds-hd -fstype=nfs4,rw,sec=krb5,vers=4.0,nosuid,nodev lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02<br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file, e.g.:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the shares.<br />
<br />
== access your data ==<br />
'''Attention!''' The access can not be done as root user, because root uses the Kerberosticket of the machine, which does not have data access! <br />
<br />
To access your data on SDS@hd you have to fetch a valid kerberos ticket with your SDS@hd user and Servicepassword:<br />
<pre><br />
> kinit hd_xy123<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
</pre><br />
You can check afterwards your kerberos ticket with:<br />
<pre><br />
> klist<br />
Ticket cache: FILE:/tmp/krb5cc_1000<br />
Default principal: hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE<br />
<br />
Valid starting Expires Service principal<br />
20.09.2017 04:00:01 21.09.2017 04:00:01 krbtgt/BWSERVICES.UNI-HEIDELBERG.DE@BWSERVICES.UNI-HEIDELBERG.DE<br />
renew until 29.09.2017 13:38:49<br />
</pre><br />
<br />
Afterwards you should be able to access the mountpoint, which contain all Speichervorhaben exported to your machine:<br />
<pre><br />
> ls <mountpoint><br />
sd16j007 sd17c010 sd17d005<br />
</pre><br />
<br />
== renew a kerberos ticket ==<br />
Because a kerberos ticket has a limited lifetime (default: 10 hours, maximum 24 hours) for security reasons, you have to renew your ticket before it expires to prevent access loss.<br />
<pre><br />
> kinit -R<br />
</pre><br />
<br />
This renewal could only be done for maximum time of 10 Days and as long as the current kerberos ticket is still valid. For renewal of an expired ticket, you have to use again your Servicepassword.<br />
<br />
== destroy kerberos ticket ==<br />
Even if kerberos tickets are only valid for a limited period of time, a ticket should be destroyed as soon as access is no longer needed to prevent misuse on multi-user systems:<br />
<pre>kdestroy</pre><br />
<br />
== automated kerberos tickets ==<br />
<span style="color:red"><strong>'''Attention!''' Keep this generated Keytab safe and use it only in trusted environments!</strong></span><br />
<br />
If your workflow needs a permanent access to SDS@hd for longer than 10 Days, you can use '''ktutil''' to encrypt your Service Password into a keytab file:<br />
<br />
''interactive way:''<br />
<pre><br />
ktutil<br />
ktutil: addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e rc4-hmac<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE:<br />
ktutil: addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e aes256-cts<br />
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE:<br />
ktutil: wkt xy123.keytab<br />
ktuitl: quit<br />
</pre><br />
<br />
''non-interactive way:''<br />
<pre><br />
echo -e "addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e rc4-hmac\n<your_servicepasword>\n<br />
addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e aes256-cts\n<your_servicepasword>\nwkt xy123.keytab" | ktutil<br />
</pre><br />
<br />
With this keytab, you can fetch a kerberos ticket without an interactive password:<br />
<pre><br />
kinit -k -t xy123.keytab hd_xy123 <br />
</pre><br />
<br><br />
<br />
[[Category:Sds-hd|NFS|Kerberos]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6570Sds-hd CIFS2020-06-09T11:44:21Z<p>S Siebler: /* Creation of a network drive with Finder */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!--<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
--><br />
<br><br />
<br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!-- path outdated:<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
--><br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0,mfsymlinks //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,mfsymlinks,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6569Sds-hd CIFS2020-06-09T11:43:52Z<p>S Siebler: /* Creation of a network (pseudo) drive with Windows Explorer */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<!--<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
--><br />
<br><br />
<br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0,mfsymlinks //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,mfsymlinks,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6522Sds-hd CIFS2020-04-30T12:26:19Z<p>S Siebler: /* Mounting a SDS@hd Share */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0,mfsymlinks //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,mfsymlinks,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0,mfsymlinks ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6521Sds-hd CIFS2020-04-30T09:24:10Z<p>S Siebler: /* AutoFS Setup */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0 //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6516Sds-hd CIFS2020-04-27T15:16:57Z<p>S Siebler: /* SMB Client */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0 //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_idmapping&diff=6515Sds-hd idmapping2020-04-27T15:13:53Z<p>S Siebler: </p>
<hr />
<div>== SDS@hd ID-Mapping ==<br />
<br />
ID-Mapping allows you to map the uidNumbers/gidNumbers of SDS@hd accounts to more descriptive usernames. <br />
<br />
If ID-Mapping is not or not correct configured, the ownerships and permissions of files/folders you see in the filesystem, will be incorrect. This could be confusing for users, but nevertheless the permission checking is done correctly on serversite.<br />
<br />
Because [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/configuring_domains SSSD] is one of the standard tools and it supports more than one ldap/identity provider on a system, we are showing here an example configuration for this tool.<br />
<br />
But of course you can use any other mechanism/tool to do the LDAP queries for ID Mapping if you want.<br />
The connection to SDS@hd LDAP Server is authenticated with the kerberos keytab of your machine. You can use any tool which supports GSSAPI with kerberos for authentication with the following parameters:<br />
* uri: ldap://bwservices.uni-heidelberg.de<br />
* search_base: dc=bwservices,dc=uni-heidelberg.de,dc=de<br />
* sasl mech: GSSAPI Authentication<br />
* krb5 Realm: BWSERVICES.UNI-HEIDELBERG.DE<br />
<br />
<br />
If you don't need a [[Sds-hd_nfs#Prerequisites|machine keytab]], but you still need ID Mapping (e.g. for CIFS Mounts on linux), you can use your Servicepassword to [[Sds-hd_nfs#automated_kerberos_tickets|create a user keytab]] for LDAP authentication.<br />
<br />
=== Example configuration of SSSD ===<br />
<br />
The authentication to SDS@hd is done via kerberos. <br />
<br />
If you have setup a working [[Sds-hd_kerberos|kerberos environment]], you have to install the needed packages for kerberos and SSSD, e.g:<br />
<br />
* RedHat/CentOS:<br />
<pre>$ yum install sssd-client sssd-krb5 sssd-ldap</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install sssd sssd-krb5 sssd-ldap sssd-tools libnss-sss libsasl2-modules-gssapi-mit</pre><br />
<br />
If not existing, create a SSSD configuration file (/etc/sssd/sssd.conf) like this:<br />
<pre><br />
[sssd]<br />
domains = BWSERVICESAD<br />
config_file_version = 2<br />
services = nss<br />
<br />
[domain/BWSERVICESAD]<br />
id_provider = ldap<br />
ldap_uri = ldap://bwservices.uni-heidelberg.de<br />
ldap_search_base = dc=bwservices,dc=uni-heidelberg,dc=de<br />
ldap_referrals = false<br />
<br />
ldap_schema = ad<br />
ldap_id_mapping = true<br />
min_id = 2000<br />
<br />
ldap_sasl_mech = GSSAPI<br />
krb5_realm = BWSERVICES.UNI-HEIDELBERG.DE<br />
ldap_sasl_authid = <HOSTNAME$ or Username><br />
ldap_krb5_keytab = <path_to_your_keytab><br />
krb5_server = bwservices.uni-heidelberg.de<br />
ldap_sasl_canonicalize = false<br />
krb5_canonicalize = false<br />
<br />
use_fully_qualified_names = true<br />
full_name_format = %3$s\%1$s<br />
<br />
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))) <br />
enumerate = false<br />
</pre><br />
<br />
<span style="color:red">Attention: </span> '''Don't forget to change "ldap_sasl_authid" to the Hostname/Username corresponding to your keytab file and the path to your keytab (e.g. /etc/krb5.keytab)!'''<br />
<br />
If you are allready using another service for authentication or name resolution on the machine, an additional domain block can be set up for this and has to be added to the line "domains".<br />
<br />
To enable SSSD for ID-Mapping in your system the lines "passwd" and "group" in file "/etc/nssswitch.conf" have to be extended by "sss", e.g.:<br />
<pre><br />
$ cat /etc/nssswitch.conf<br />
[...]<br />
passwd: compat sss<br />
group: compat sss<br />
</pre><br />
<br />
'''Note''': If you are using sssd you should not use "nscd" in parallel! Otherwise this could lead to undefined behaviour due to double caching passwd and group entries.<br />
<br />
After configuring SSSD you should enable and restart the service, e.g.:<br />
<pre><br />
$ systemctl enable sssd.service <br />
$ systemctl restart sssd.service<br />
</pre><br />
<br />
[[Category:Sds-hd|NFS|Kerberos]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6514Sds-hd CIFS2020-04-27T15:11:41Z<p>S Siebler: /* Mount over command line */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0 //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep lsdf02<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6513Sds-hd CIFS2020-04-27T15:10:05Z<p>S Siebler: /* Using SMB/CIFS for UNIX client */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
$ smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/sds-hd<br />
<br />
$ sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0 //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
$ df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
$ cd /mnt/sds-hd/<br />
$ ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
$ mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
$ cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
$ mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
$ mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>$ yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>$ apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>$ alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>$ sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
$ update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
$ yum install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
$ apt install autofs<br />
$ systemctl enable autofs <br />
$ systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
$ cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
$ cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
$ cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
$ systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
$ kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6512Sds-hd CIFS2020-04-27T12:36:09Z<p>S Siebler: /* Access the Share */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0 //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
For further information about handling kerberos ticket take a look at [[Sds-hd_nfs#access_your_data|SDS@hd kerberos]]<br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6511Sds-hd CIFS2020-04-27T12:33:23Z<p>S Siebler: /* Using SMB/CIFS for UNIX client */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0 //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== ID Mapping ====<br />
<br />
In a Multiuser Environment it is important to get the correct ownerships and permissions from the server. Therefor you need to setup a [[Sds-hd_idmapping|ID Mapping]] environment.<br />
<br />
Additionally we need the following packages to enable CIFS Mapping:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils keyutils</pre><br />
<br />
After [[Sds-hd_idmapping|installing SSSD]] you have to ensure that it will be used for CIFS name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for ID mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6510Sds-hd CIFS2020-04-27T12:19:41Z<p>S Siebler: /* Using SMB/CIFS for UNIX client */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, server side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils keyutils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0 //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6509Sds-hd CIFS2020-04-27T12:18:45Z<p>S Siebler: /* Mounting a SDS@hd Share */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils keyutils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required. <br />
<br />
CIFS normally binds all shares on the client as the property of the user who mounted them and transfers any existing write rights only to the user. With additional information from uid, gid, file_mode and dir_mode, other ownership and access rights can be defined when mounting on the client. <br />
<br />
'''Nevertheless the ownership and access rights defined in this way are only simulated on the client and are not really transferred to the server.''' If access rights are changed on the client or files with other owners are created in shared folders, these changes only apply to the client and only until the next remount.<br />
<br />
If you need to work with the correct server side permissions, please follow the setup of a [[Sds-hd_CIFS#Multiuser Environment|MultiUser Setup]]<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,vers=3.0 //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs uid=<YOUR_UID>,gid=<YOUR_GID>,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint and the correct permission/ownership processing, the mount options <pre>multiuser,cifsacl</pre> have to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, you can use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you configure the SDS@hd Speichervorhaben in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6503Sds-hd CIFS2020-04-27T11:15:17Z<p>S Siebler: /* Using SMB/CIFS for UNIX client */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils keyutils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
On debian systems SSSD has to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required.<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
or<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,sec=krb5,noauto 0 0<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint the mount option <pre>multiuser</pre> has to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, youcan use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you can configure the needed SDS@hd shares in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6500Sds-hd CIFS2020-04-27T11:01:55Z<p>S Siebler: /* Mount over /etc/fstab */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils keyutils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
In debian systems SSSD have to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required.<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
or<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,sec=krb5,noauto 0 0<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint the mount option <pre>multiuser</pre> has to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, youcan use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you can configure the needed SDS@hd shares in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6499Sds-hd CIFS2020-04-27T11:00:58Z<p>S Siebler: /* Mount over /etc/fstab */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils keyutils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
In debian systems SSSD have to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required.<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
or<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,sec=krb5,cruid=<UID*>,noauto 0 0<br />
<br />
* local UID of the mounting user, can be retrieved with "id" command<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint the mount option <pre>multiuser</pre> has to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, youcan use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you can configure the needed SDS@hd shares in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6498Sds-hd CIFS2020-04-27T10:56:47Z<p>S Siebler: /* Using SMB/CIFS for UNIX client */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils keyutils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils keyutils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
In debian systems SSSD have to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required.<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
or<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,sec=krb5,noauto 0 0<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint the mount option <pre>multiuser</pre> has to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, youcan use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you can configure the needed SDS@hd shares in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6497Sds-hd CIFS2020-04-27T10:42:43Z<p>S Siebler: /* Mount over command line */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
In debian systems SSSD have to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required.<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>sudo mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
or<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,sec=krb5,noauto 0 0<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint the mount option <pre>multiuser</pre> has to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, youcan use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you can configure the needed SDS@hd shares in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6496Sds-hd CIFS2020-04-27T10:41:05Z<p>S Siebler: /* Mount over command line */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
In debian systems SSSD have to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required.<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
or<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,sec=krb5,noauto 0 0<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint the mount option <pre>multiuser</pre> has to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, youcan use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you can configure the needed SDS@hd shares in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6495Sds-hd CIFS2020-04-27T10:39:56Z<p>S Siebler: /* Mount over /etc/fstab */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
In debian systems SSSD have to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required.<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
or<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
>mount -t cifs -o sec=krb5,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
or<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,user,vers=3.0,sec=krb5,noauto 0 0<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint the mount option <pre>multiuser</pre> has to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, youcan use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you can configure the needed SDS@hd shares in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6490Sds-hd CIFS2020-04-27T10:18:12Z<p>S Siebler: /* AutoFS Setup */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
In debian systems SSSD have to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required.<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
or<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
>mount -t cifs -o sec=krb5,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
or<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,sec=krb5,noauto 0 0<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint the mount option <pre>multiuser</pre> has to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, youcan use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
Afterwards you can configure the needed SDS@hd shares in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Sieblerhttps://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_CIFS&diff=6488Sds-hd CIFS2020-04-27T10:15:39Z<p>S Siebler: /* Using SMB/CIFS for UNIX client */</p>
<hr />
<div>= <b> Prerequisites </b>=<br />
<br />
'''Attention:''' To access data served by SDS@hd via CIFS, You need a '''''Service Password'''''. See details [[Sds-hd_user_access|SDS@hd Access]].<br />
<br />
Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html belwue-Network].<br />
<br />
This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via [https://www.eduroam.org/where/ eduroam] or from your personal Laptop)<br />
<br />
= <b> Using SMB/CIFS for Windows client </b> =<br />
<br />
You can use a CIFS share from a Microsoft operating system.<br />
<br />
== Adopting Universal Naming Convention (UNC) syntax ==<br />
<br />
Use Windows Explorer entering the path to the share in UNC syntax:<br />
<br />
'''Examples:'''<br />
<br />
<pre><br />
\\lsdf02.urz.uni-heidelberg.de <br />
or<br />
\\lsdf02.urz.uni-heidelberg.de\<sv-acronym><br />
</pre><br />
<br />
Following the input of the UNC path, a window will pop up: <br><br />
'''Loginname:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
<br><br><br />
Following authentication a new window pops up, showing the content of the share.<br />
You can now manipulate your files as accustomed.<br />
[[File:Sds-hd-smb-auth.png ]]<br />
<br />
== Creation of a network (pseudo) drive with Windows Explorer==<br />
<br />
To connect to a network share in Windows Explorer select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' \\lsdf02.urz.uni-heidelberg.de\<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds-hd-smb-netdrive.png|500px|center|border ]]<br />
<br />
<br><br />
= <b>Using SMB/CIFS for Mac OS client </b> =<br />
<br />
== Creation of a network drive with Finder ==<br />
<br />
To connect to a network share in Finder select the control field<br><br />
Select a drive letter to be associated with the network share and enter the network path (e.g. \\lsdf02.urz.uni-heidelberg.de). Select ‘use a different identification‘, as these differ from your credential used locally.<br />
<br><br><br />
'''Path:''' smb://lsdf02.urz.uni-heidelberg.de/<sv-acronym> <br><br />
'''Username:''' BWSERVICESAD\hd_xy123 <br><br />
'''Password:''' ''Service Password''<br />
[[File:Sds_smb_mac_mountpath.png|350px|left|border ]] [[File:Sds_smb_mac_login.png|350px|center|border ]]<br />
<br />
= <b> Using SMB/CIFS for UNIX client </b> =<br />
<br />
A UNIX like operating system needs a CIFS client to use a share. CIFS clients are part of Samba implementation for Linux and other UNIX like operating systems (http://www.samba.org)<br />
<br />
'''Attention:''' <br />
The core CIFS protocol does not provide unix ownership information or mode for files and directories. <br />
Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. '''Attempting to change these values via chmod/chown will return success but have no effect.'''<br />
<br />
For security reasons, Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.<br />
<br />
Although mapping of POSIX UIDs and SIDs is not needed mounting a CIFS share '''it might become necessary when working with files on the share, e.g. when modifying ACLs'''.<br />
<br />
<!--<br />
For this reason the mount option <pre>cifsacl</pre> together with a working '''ID Mapping''' setup is required, to allow correct permission handling and changes. It offers also the tools <br />
<pre><br />
getcifsacl<br />
setcifsacl<br />
</pre><br />
to work with ACLs.<br />
<br />
With version 5.9 of cifs-utils a plugin interface was introduced by Jeff Layton to allow services other than winbind to handle the mapping of POSIX UIDs and SIDs. SSSD will provide a plugin to allow the cifs-utils to ask SSSD to map the ID. With this plugin a SSSD client can access a CIFS share with the same functionality as a client running Winbind.<br />
<br />
For this reason we can use the same [[Sds-hd_nfs#configure kerberos environment for SDS@hd|SSSD setup]] for cifs like we use for the kerberized nfs-Setup. <br />
--><br />
<br />
{{:Sds-hd_idmapping}}<br />
<br />
Additionally we need the cifs packages:<br />
* RedHat/CentOS:<br />
<pre>> yum install cifs-utils</pre><br />
* debian/ubuntu:<br />
<pre>> apt install cifs-utils</pre><br />
<br />
After installing SSSD you have to ensure that it will be used for cifs name resolution, e.g.<br />
<br />
* RedHat/CentOS:<br />
On RedHat SSSD should have allready a higher priority than winbind:<br />
<pre>> alternatives --display cifs-idmap-plugin<br />
<br />
cifs-idmap-plugin - Status ist automatisch.<br />
Link verweist auf /usr/lib64/cifs-utils/cifs_idmap_sss.so<br />
/usr/lib64/cifs-utils/cifs_idmap_sss.so - priority 20<br />
/usr/lib64/cifs-utils/idmapwb.so - priority 10<br />
Zur Zeit ist die `best' Version /usr/lib64/cifs-utils/cifs_idmap_sss.so.<br />
</pre><br />
<br />
* debian/ubuntu:<br />
In debian systems SSSD have to be registered for id mapping with an higher priority than winbind:<br />
<br />
<pre>> sudo update-alternatives --install /etc/cifs-utils/idmap-plugin idmap-plugin /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so 50<br />
<br />
> update-alternatives --display idmap-plugin<br />
idmap-plugin - automatischer Modus<br />
beste Version des Links ist /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link verweist zur Zeit auf /usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so<br />
Link idmap-plugin ist /etc/cifs-utils/idmap-plugin<br />
Slave idmap-plugin.8.gz ist /usr/share/man/man8/idmap-plugin.8.gz<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/cifs_idmap_sss.so - Priorität 50<br />
/usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so - Priorität 40<br />
Slave idmap-plugin.8.gz: /usr/share/man/man8/idmapwb.8.gz<br />
</pre><br />
<br />
<br />
== SMB Client ==<br />
<br />
'''Example:'''<br />
To list the files in a SMB share, use the program smbclient.<br />
<pre><br />
smbclient -U 'BWSERVICESAD\hd_xy123' //lsdf02.urz.uni-heidelberg.de/<sv-acronym><br />
Enter BWSERVICESAD\hd_xy123's password: <br />
</pre><br />
<br />
The program allows you to access the files with a FTP like tool in an interactive shell.<br />
<pre><br />
>smbclient //lsdf02.urz.uni-heidelberg.de/<sv-acronym> -U 'BWSERVICESAD\hd_xy123'<br />
Enter BWSERVICESAD\hd_xy123's password:<br />
smb: \> ls<br />
. D 0 Thu Apr 23 12:51:48 2020<br />
.. D 0 Wed Apr 22 21:54:04 2020<br />
bench D 0 Fri Jul 26 10:24:05 2019<br />
benchmark_test D 0 Tue Oct 30 16:12:21 2018<br />
checksums D 0 Mon Sep 18 10:24:21 2017<br />
test.multiuser A 6 Thu Apr 23 12:36:07 2020<br />
test A 7 Thu Apr 23 09:38:13 2020<br />
.....<br />
.snapshots DHR 0 Thu Jan 1 01:00:00 1970<br />
<br />
115343360000 blocks of size 1024. 108260302848 blocks available<br />
smb:\<br />
</pre><br />
<br />
== Mounting a SDS@hd Share ==<br />
<br />
Mounting a SDS@hd CIFS share can be done by using username/password credentials or by using kerberos tickets.<br />
Information about settting up a kerberos environment for SDS@hd can be found [[Sds-hd_kerberos|*here*]]'''.<br />
<br />
=== Single-User Environment ===<br />
<br />
A share can be mounted to a local directory, (e.g. /mnt/sds-hd ). Depending on your system setup, root privileges may be required.<br />
<br />
==== Mount over command line ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/sds-hd<br />
<br />
>mount -t cifs -o username=hd_xy123,domain=BWSERVICESAD,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
Password:<br />
<br />
or<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
>mount -t cifs -o sec=krb5,cifsacl //lsdf02.urz.uni-heidelberg.de/<sv-acronym> /mnt/sds-hd<br />
<br />
>df -h | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 108T 6,6T 101T 7% /mnt/sds-hd<br />
<br />
>cd /mnt/sds-hd/<br />
>ls<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep sds-hd<br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/sds-hd type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
==== Mount over /etc/fstab ====<br />
<br />
'''Example:'''<br />
<br />
<pre><br />
>mkdir /mnt/mountpoint<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,credentials=<path_to_user_HOME>/credentialsfile,noauto 0 0<br />
<br />
>cat /path_to_user_HOME/credentialsfile<br />
username=hd_ xy123<br />
password=<your_servicepassword><br />
domain=BWSERVICESAD<br />
<br />
or<br />
<br />
/etc/fstab<br />
//lsdf02.urz.uni-heidelberg.de/<sv_acronym> /mnt/mountpoint cifs cifsacl,sec=krb5,noauto 0 0<br />
<br />
> kinit hd_xy123<br />
Passwort für hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: <br />
<br />
>mount /mnt/mountpoint<br />
</pre><br />
Verify the success of the mount invoking the mount command without any arguments:<br />
<pre><br />
mount | grep cifs <br />
//lsdf02.urz.uni-heidelberg.de/sd16j007 on /mnt/mountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=xxxx,domain=BWSERVICESAD,uid=1000,forceuid,gid=0,noforcegid,addr=xxxxx,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)<br />
</pre><br />
<br />
<br />
=== Multiuser Environment ===<br />
<br />
By default, CIFS mounts only use a single set of user credentials (the mount credentials) when accessing a share. To support different user session on the same mountpoint the mount option <pre>multiuser</pre> has to be used. Because the kernel cannot prompt for passwords, '''multiuser mounts are limited to mounts using passwordless sec= options, like with sec=krb5. Information about settting up a kerberos environment can be found [[Sds-hd_kerberos|*here*]]'''<br />
<br />
==== AutoFS Setup ====<br />
<br />
Because CIFS shares, in contrast to nfs-Mounts, have to be mounted directly, the root user can not simply mount them into a global folder. Instead the shares have to be initially mounted by a user who has access to the Share. To achieve this, youcan use the automounter "autofs".<br />
<br />
* RedHat/CentOS:<br />
<pre><br />
> yum install autofs<br />
> systemctl enable autofs <br />
> systemctl start autofs <br />
</pre><br />
<br />
* debian/ubuntu:<br />
<pre><br />
> apt install autofs<br />
</pre><br />
<br />
Afterwards you can configure the needed SDS@hd shares in a new map file:<br />
<pre><br />
> cat /etc/auto.sds-hd<br />
<sv-acronym1> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym1><br />
<sv-acronym2> -fstype=cifs,cifsacl,multiuser,sec=krb5,cruid=${UID},vers=3.0 ://lsdf02.urz.uni-heidelberg.de/<sv-acronym2><br />
....<br />
</pre><br />
<br />
You have to include the new map into the auto.master file:<br />
<pre><br />
cat /etc/auto.master<br />
[...]<br />
/mnt/sds-hd /etc/auto.sds-hd<br />
[...]<br />
</pre><br />
<br />
To display all available SDS@hd shares on this machine to the users, you should enable "browser_mode":<br />
<pre><br />
cat /etc/autofs.conf<br />
[...]<br />
# to display all available SDS-hd shares on this to the users<br />
browse_mode=yes<br />
[...]<br />
</pre><br />
otherwise each share-folder will only be visible after a user has mounted.<br />
<br />
Of course you can adopt all other autofs options, like timeouts, etc. to the specific needs of your environment or use any other method for dynamically mounting the CIFS shares.<br />
<br />
After changing the configuration, you should restart the autofs daemon, e.g.:<br />
<pre><br />
systemctl restart autofs<br />
</pre><br />
<br />
==== Access the Share ====<br />
<br />
Now each user should be able to mount a SDS@hd share, which is configured for the machine. If a share is allready mounted, other users will access this share with their own credentials without mounting again.<br />
<br />
To get access, each user needs a valid kerberos ticket, which can be fetched with<br />
<pre><br />
> kinit hd_xy123<br />
</pre><br />
<br />
<br><br />
<hr><br />
<br><br />
<br><br />
<br><br />
<br><br />
[[Category:Sds-hd|CIFS|SMB]]</div>S Siebler