====== Documentation utilisateur ====== ===== Data retention ===== **NB**, part of the following instructions come from (( https://doc.eresearch.unige.ch/nasac-admin/nasac_administration?rev=1663845916#snapshot )). ==== Snapshots ==== **NB**, this originates from (( https://support-si.unige.ch/openentry.html?tid=INC000000304350 )). First of all, which snapshots do we keep? Please check the Plone documentation if you are looking for informations about the old **NAS bureautique** (nowadays //nasac-faculty//): \\ https://plone.unige.ch/distic/pub/nas-bureautique/nas-bureautique-accueil#spec-quota * **4hourly** : 1 snapshot chaque 4 heures, avec une queue de **42**. Nous conservons donc un historique d'une semaine. In the middle of the current week, the **4hourly** snapshots will span two weeks (the previous one and the current one)! * **weekly** : 1 snapshot par semaine (le dimanche) avec une queue de **6**. Nous conservons donc un historique d'un mois et demi (6 semaines). This is not a **consolidation** of the **4hourly** snapshots, but a completely independent process! Then, how to access them? * //Windows//: in the ''File Explorer'': \\ => right-click on the folder (either at the share root or at any sub-folder), then ''Properties -> Previous Versions'' * //Mac or Linux//: \\ => enter the ''.snapshot'' **hidden** folder ==== Replication ==== **NB**, this originates from (( https://gitlab.unige.ch/storage/hpfs/-/issues/3 )). To assure the service continuity in case of problems in the primary UNIGE DC at UniDufour, a **nightly** replication is automatically done at the secondary UNIGE DC at the Campus Biotech. The main differences for the NAS infrastructure at the Campus Biotech are: - 2 old nodes (4080 models //vs.// the 5300 at UniDufour) - nor **4hourly** neither **weekly** snapshots, but **daily** ones (automatically taken **before** the nightly replication starts) - no end-user access ==== Backups ==== **NB**, this originates from (( https://support-si.unige.ch/openentry.html?tid=WO0000000225023 )). For anti-ransomware reasons, we also have a backup on tape of each NAS share, thus completely independent from the NAS infrastructure. Some notes: - while our goal is to have **3day** backups, we assure only at least a **weekly** backup. - data that has been deleted from the NAS share is kept up to **2 years** after the deletion date. Then, how to access them? These backups are not (and will never be) directly accessible to the end-user, but you need to contact [[storage@unige.ch|]] to have more information about the date availability and to recover data! ===== Data transfer ===== ==== Migrate data to UNIGE tape solution ==== **NB**, this originates from (( https://gitlab.unige.ch/storage/tickets/-/issues/365#note_253404 )) (( )) If you want to migrated NAS data (actually, **any data**...) to the UNIGE tape solution (cf. https://catalogue-si.unige.ch/tape, based on IBM Spectrum Archive), you can use the ''ug-nas-create-zip-archive-from-folder.sh'' from the [[https://gitlab.unige.ch/storage/nas/ug-nas/-/blob/main/misc/ug-nas-create-zip-archive-from-folder.sh|ug-nas]] project, which: - calculate the size of the source folder - calculate the MD5 hashes for each file in the source folder - create a 2GB-by-default **split** (AKA multiple-file) ''.zip'' archive in the destination folder - list the destination folder content - delete the source folder and all its content Given that InfoZip ''unzip'' does not support (yet) **split archives**, to decompress the files generated by ''ug-nas-create-zip-archive-from-folder.sh'' you must use ''7-Zip'' (cf. https://7-zip.org, the old ''p7zip'' Linux port works as well) on the last file, thus ''7za x ${ARCHIVE}.zip''! $ ug-nas-create-zip-archive-from-folder.sh -h UG-NAS: Create a split ZIP archive from a NAS folder Usage: ug-nas-create-zip-archive-from-folder.sh [-h] [-s ] Options: -h : display this help and exit -s : split at GB (defaults to 2) $ ug-nas-create-zip-archive-from-folder.sh \ "/path/to/source/folder" \ "/path/to/destination/folder" \ 2>&1 | \ tee "/path/to/log/folder/$(date +%Y%d%m)_ug-nas-create-zip-archive-from-folder_${SOURCE_FOLDER}.log" Thu 16 Nov 2023 11:48:49 AM CET ===== I: calculating source folder size... 3.9G ===== Thu 16 Nov 2023 11:48:49 AM CET ===== I: generating MD5 checksum for each file in source folder... [...] real 1m3.094s user 0m7.158s sys 0m1.736s ===== Thu 16 Nov 2023 11:49:52 AM CET ===== I: creating the split ZIP archive... splitsize = 2147483648 [...] total bytes=4098480958, compressed=3899876027 -> 5% savings real 2m48.380s user 2m30.320s sys 0m5.719s ===== Thu 16 Nov 2023 11:52:40 AM CET ===== I: listing archive folder '/path/to/destination/folder' content: total 3768321 [...] ===== Thu 16 Nov 2023 11:52:40 AM CET ===== I: deleting the source folder... real 0m0.073s user 0m0.004s sys 0m0.029s ===== Thu 16 Nov 2023 11:52:40 AM CET ===== I: all done! $ ==== Access from outside the UNIGE network ==== **NB**, this originates from (( )). The UNIGE central NAS is available only from within the UNIGE internal network (including the VPN access). Depending on the access type you need from the outside world, you should: - ask to activate the share in your **EduCloud** account (cf. https://plone.unige.ch/distic/pub/logiciels/filr-switchdrive) if access is restricted on specific files - ask for an **external UNIGE ISIs account** (cf. https://catalogue-si.unige.ch/en/isis) if access to a large amount of data is needed or analysis must be directly made on such data (//e.g.// for a //independent contractor//) - duplicate the data stored on the UNIGE central NAS to the UNIGE central S3 service and then create pre-signed S3 URLs (cf. https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html) \\ **ATTENTION**, this means you must pay both the NAS and the S3 spaces! If you need to **regularly** transfer data from/to the UNIGE central NAS, the **external UNIGE ISIs account** is currently the best option, please contact us to set up the [[#rsync|restricted rsync-over-SSH access]]. ==== rsync ==== **NB**, the following instructions come from (( https://gitlab.unige.ch/prods/ies/recherche/hpc/issues/900#note_32016 )) (( https://gitlab.unige.ch/storage/tickets/-/issues/40 )) If you need to synchronize data to another folder, you can let `rsync` **3.1.0+** saves in the log file the MD5 checksum of any transferred file (cf. https://stackoverflow.com/questions/29624524/how-can-i-print-log-the-checksum-calculated-by-rsync#45053057): $ rsync \ --log-file=/path/to/file.log \ --log-file-format="%C %f" \ [...] \ "${SOURCE_FOLDER}" \ "${TARGET_FOLDER}" $ grep -e "${SOURCE_FOLDER}" /path/to/file.log | \ cut -c 29- | \ awk '{if ($2 != "") {print $0}}' | \ sed -e "s, ${SOURCE_FOLDER}/, ,g" \ >"/path/to/${SOURCE_FOLDER}.md5" $ cd "${TARGET_FOLDER}" $ md5sum -c "/path/to/${SOURCE_FOLDER}.md5" ===== Statistiques utilisation ===== TreeSize est lancé sur certains share de manière périodique. https://plone.unige.ch/distic/acteurs-du-si/distic/prods/pole-environnement-de-travail-et-integration/serveurs/serveur-de-statistique/liste-des-partages-scanner ===== Utilisation d'un partage SMB ===== **NB**, this partly originates from (( https://gitlab.unige.ch/storage/tickets/-/issues/577 )) (( )) (( )). There are 3 different actors involved in the life of an SMB share: - the **DiSTIC RISE storage team** \\ => the infrastructure administrators and share configurators (allocated space, ACL administrative access and pass-through access) - the share **owner** (AKA ''contact_owner'') \\ => the one responsible for the share content (thus deciding who has access to them), also providing the billing information - the share **administrators** (AKA ''contact_admin'') \\ => the share content managers Please follow the links on the [[https://catalogue-si.unige.ch/stockage-recherche|catalogue des services informatiques, section "Obtenir une prestation"]] to ask for a new share or a modification to an existing one, as well as to report a problem. Please check the [[#how_to_manage_smb_acls_aka_permissions|how to manage the ACLs (AKA permissions)]] section to understand how the ACLs are configured and to be managed! Lorsqu'un partage a été crée et que votre CI vous a donné les droits d'accès (cf. [[#how_to_manage_smb_acls_aka_permissions|how to manage the ACLs (AKA permissions)]]), suivez la procédure ci-dessous pour vous connecter à votre partage. A noter que pour vous connecter à un partage depuis l'extérieur de l'université, vous devez configurer et lancer votre VPN. Veuillez vous référer à la documentation du VPN de l'unige pour ce faire. If you experience problems connecting from a Mac, you can test **SMB browsing** via the ''[[https://gitlab.unige.ch/storage/nas/ug-nas/-/blob/main/tools/ug-nas-test-smb-browsing.sh|ug-nas-test-smb-browsing.sh]]'' script! ==== Problèmes connus avec produits Adobe ==== **NB**, this originates from (( https://support-si.unige.ch/openentry.html?tid=INC000000281029 )) (( https://support-si.unige.ch/openentry.html?tid=WO0000000235256 )) Les produits Adobe sont de plus en plus "strictes" par rapport aux disques réseaux : - Photoshop ne support pas le disques réseaux : \\ https://support-si.unige.ch/openentry.html?tid=INC000000281029 \\ https://helpx.adobe.com/photoshop/kb/networks-removable-media-photoshop.html - Acrobat "Protected Mode" ne permet pas de sauvegarder des PDFs sur des disques réseaux : \\ https://community.adobe.com/t5/acrobat-reader-discussions/save-as-in-network-drive-not-possible/td-p/9000860?profile.language=fr \\ https://community.adobe.com/t5/acrobat-discussions/error-while-saving-a-pdf-file-to-a-mapped-drive/td-p/5270686 ==== Allocated space for an SMB share ==== First of all, you need to mount the **share root** (thus, not a super/sub-folder). Then * //Windows//: in the ''File Explorer'': \\ => right-click on the folder (either at the share root or at any sub-folder), then ''General -> Capacity'' * //Mac or Linux//: \\ => in a terminal df -h /path/to/the/mounted/share ==== List all the shares you have access ===== **NB**, part of the following instructions come from (( )). Here the commands to get the list of all the shares you have access on a specific server: - Windows (( https://superuser.com/questions/274640/list-network-shares-from-command-prompt#274641 )): PS C:\WINDOWS\system32> net view \\nasac-faculty.unige.ch /all | Select-String Disk [...] PS C:\WINDOWS\system32> (net view \\nasac-faculty.unige.ch /all | Select-String Disk).length 107 PS C:\WINDOWS\system32> - GNU/Linux: \\ **ATTENTION**, unfortunately '''smbclient -L''' does not allow "grep-piping" if interactive! capello@harlock:~$ smbclient -L nasac-faculty.unige.ch -W ISIS -U capello Enter ISIS\capello's password: Sharename Type Comment --------- ---- ------- [...] SMB1 disabled -- no workgroup available capello@harlock:~$ cat <~/.smbclient username = capello password = ${ISIS} domain = ISIs EOF capello@harlock:~$ smbclient -L nasac-faculty.unige.ch -W ISIS -A ~/.smbclient | grep -c Disk 107 capello@harlock:~$ ==== Connection depuis linux ==== La procédure est sensiblement la même pour d'autres variantes de Linux. The official DiSTIC documentation for the personal space provided by the UNIGE is available at https://plone.unige.ch/distic/pub/nas-bureautique/comment-configurer-les-repertoires-personnels-et-partages-sous-ubuntu ! === Command line === **NB**, this originates from (( https://gitlab.unige.ch/storage/tickets/-/issues/919 )). - via plain old ''mount'' command, which however requires **superuser** privileges and the **cifs** kernel module: root@harlock:~# findmnt /mnt root@harlock:~# mount \ -t cifs \ -o vers=3,sec=ntlmsspi,domainauto,username=capello \ //nasac-faculty.isis.unige.ch/ADM_HOME/DISTIC/capello \ /mnt/ Password for capello@//nasac-faculty.isis.unige.ch/ADM_HOME/DISTIC/capello: root@harlock:~# findmnt /mnt TARGET SOURCE FSTYPE OPTIONS /mnt //nasac-faculty.isis.unige.ch/ADM_HOME/DISTIC/capello cifs rw,relatime,vers=3,sec=ntlmsspi,cache=strict,username=capello,domain=ISIS,uid=0,noforceuid,gid=0,noforcegi root@harlock:~# - via GVfs/Gio (//i.e.// the same "helper" framework used by most of the graphical tools including the default Ubuntu desktop), which is an unprivileged action with its own non-kernel SMB implementation: capello@harlock:~$ gio mount smb://nasac-faculty.isis.unige.ch/ADM_HOME/DISTIC/capello Password required for share adm_home on nasac-faculty.isis.unige.ch User [capello]: Domain [WORKGROUP]: ISIs Password: capello@harlock:~$ ls -l /run/user/$(id -u)/gvfs/ total 2 drwx------ 1 capello capello 2048 Nov 30 11:50 smb-share:server=nasac-faculty.isis.unige.ch,share=adm_home capello@harlock:~$ === Graphical interface === Se connecter à un serveur: {{ nasac:smb_connect_from_linux_01_connect_to_a_server.png | Connection à un serveur }} Choisir l'ip ou le nom de votre EVS (transmis par votre CI): {{ nasac:smb_connect_from_linux_02_enter_the_ip_address.png | Choix de l'EVS }} Entrer vos identifiants ISIS: {{ nasac:smb_connect_from_linux_03_enter_credentials.png | Saisie de vos identifiants }} === Linux and SMB3+ === **NB** , the following instructions come from SMB3+ requires packet signing, thus if you encounter the following error... CIFS VFS: validate protocol negotiate failed: -13 CIFS VFS: failed to connect to IPC (rc=-5) CIFS VFS: validate protocol negotiate failed: -13 CIFS VFS: session ffff962f7cd42400 has no tcon available for a dfs referral request CIFS VFS: cifs_mount failed w/return code = -5 ...you have to specify that you want packet signing via a mount option, either sec=ntlmsspi (preferred) or sec=ntlmv2. === Linux and symlinks on SMB shares === **NB** , the following instructions come from Starting from Windows 10, symlinks (AKA symbolic links) are fully supported (cf. https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/ ). However, while Linux can make use of symlinks on a SMB share created on Windows 10, there is no way to create them on Linux. On the other hand, Linux-only symlinks on SMB shares are still possible, no more via the SMB1-only CIFS Unix Extensions (cf. https://www.samba.org/samba/CIFS_POSIX_extensions.html ), but via the new SMB3 POSIX Extensions (cf. https://wiki.samba.org/index.php/SMB3-Linux#Symbolic_links ). Specyfing the mount option mfsymlinks will allow symlink creation on Linux using the Minshall+French file format, which means that they will be seen on Windows as a plain text file (cf. https://wiki.samba.org/index.php/UNIX_Extensions#Storing_symlinks_on_Windows_servers ). **ATTENTION** , while the mount option mfsymlinks is available from SMB2+, it is preferable to use it together with SMB3+ (see [[nasac:users_documentation#linux_and_smb3|Linux and SMB3+]]). ==== Connection depuis un poste windows ne faisant pas partie du domaine ==== Connectez un lecteur réseau pour y accéder à partir de l’Explorateur de fichiers dans Windows sans avoir à le rechercher ou à saisir son adresse réseau à chaque fois. - Ouvrez l'Explorateur de fichiers à partir de la barre des tâches ou du menu Démarrer, ou appuyez sur la Touche de logo Windows + e.\\ - Sélectionnez Ce PC dans le volet de gauche. Puis, dans l'onglet Ordinateur, sélectionnez Connecter un lecteur réseau {{ nasac:smb_connect_from_windows-01-connect_network_drive.png | Connecter un lecteur réseau }} Sélection du disque et du nom du partage: {{ nasac:smb_connect_from_windows-02-choose_share.png | Sélection de l'EVS et du partage }} Saisie de vos identifiants ISIS: {{ nasac:smb_connect_from_windows-03-input-credentials.png | Saisie de vos identifiants ISIS }} === Connection refused after successful login === **NB**, this originates from (( https://gitlab.unige.ch/storage/tickets/-/issues/280 )) (( https://support-si.unige.ch/openentry.html?tid=WO0000000207049 )) (( https://gitlab.unige.ch/storage/tickets/-/issues/442 )) If you still get **connection refused** messages and you are sure your ISIs credentials are right, the IP address your computer got could have been blacklisted **in the last 15 minutes** on the NAS side because of too many SMB NTLM authentication failures. Here how to find out if you are impacted: - find out your current IP address: - Windows: ''Start -> PowerShell -> ipconfig -> IPv4 Address'' - Mac: ''Applications -> Terminal -> ifconfig | grep -e "inet "'' - Linux: ''Applications -> Terminal -> ip addr show | grep -e "inet "'' - check if your IP is listed in the last-unblocked-IP on https://luninasadm1.unige.ch/nas-smb-barred-clients-list.txt IPs are automatically unblocked every 15 minutes, to avoid continuous blocking please check your Windows Credential Manager for old-and-no-more-valid passwords (cf. https://support.microsoft.com/en-us/windows/accessing-credential-manager-1b5c916a-6a16-889f-8581-fc16e8165ac0)! ==== How to manage SMB ACLs (AKA permissions) ==== **NB**, part of the following instructions come from (( https://gitlab.unige.ch/storage/tickets/-/issues/432 )) (( https://support-si.unige.ch/openentry.html?tid=INC000000312347 )) (( https://support-si.unige.ch/openentry.html?tid=INC000000317940 )). You need at least **2 AD groups** for an SMB share to be created: - an ''admin'' one to manage the ACLs (AKA permissions) \\ => full control at the first level (thus ''\\${SERVER}\${SHARE}\''), with inheritance enabled - a ''pass-through'' one to be able to mount/connect the share \\ => list the first level content only (thus no inheritance) These 2 groups will then be used to set the ACLs of the share itself (thus the mount point), ACLs that must be modified via the administrative interface only. Once the share has been created, you must set the ACLs at least for the 1st-level content, directly from Windows: * if you are a **Correspondant Informatique**, please check the internal documentation "Affectation des droits" paragraph in the "Gestion des postes de travail avec l'Active Directory (AD)" guide available on [[https://plone.unige.ch/distic/acteurs-du-si/ci-et-webmasters/formations-ci/|Plone]]. * if you are a **end-user**, please check the external documentation at https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs#Setting_ACLs_on_a_Folder or https://docs.netapp.com/us-en/ontap/smb-admin/configure-ntfs-windows-security-tab-task.html . If you simply want to **check** the existing ACLs from a Linux machine, you can do it via ''smbcacls'' (usually shipped by the ''smbclient'' package)! ===== How to manage an NFS share ===== **NB** , the following instructions come from (( https://gitlab.unige.ch/prods/ies/recherche/hpc/issues/716 )) (( )). To know which client/IP can connect to which NFS share, you can use the command ''/sbin/showmount -e "${EVS}" | grep -e "${SHARE}"''. Please be aware that the output does not show the NFS options (the most common ones are **ro**, **rw** and **no_root_squash**), which are independent from the NFSv4 ACLs below! Nowadays most of the GNU/Linux distribution defaults to NFSv4, which is a big step forward and differs quite a lot from NFSv3 (cf. http://www.citi.umich.edu/projects/nfsv4/ ). One of the main advantages of NFSv4 is the ACLs support into the protocol itself (cf. http://wiki.linux-nfs.org/wiki/index.php/ACLs ), ACLs that resemble very much the Windows ones. The NASAC, being based on a Unix system, natively supports NFSv4 ACLs. Actually, given that it is connected to the UniGE's Active Directory, the NFSv4 ACLs are the same as the Windows ones. Here the instructions to manage the NFSv4 ACLs for a share: - client mapping does not matter, knowing that when no local mapping is possible everything is nobody:nobody (cf. https://www.thegeekdiary.com/nfsv4-mountpoint-shows-incorrect-ownerships-as-nobodynobody-in-centos-rhel/ ). \\ **ATTENTION** : * on RHEL 6.3+ NFS ID mapping is disabled by default, _i.e._ /sys/module/nfs/parameters/nfs4_disable_idmapping is set to Y (cf. https://access.redhat.com/articles/2252881 ), thus numeric UIDs/GIDs are sent over the wire. * NFSv4 ID mapping on clients is now managed by a separate process, nfsidmap (which does not run as a daemon), thus you no more need rpm.idmapd . Nevertheless, they share the same configuration file, _i.e._ /etc/idmapd.conf . - server mapping is mandatory, thus ask the NASAC administrator to map the needed users/groups via support-si . - please DO NOT USE chmod to set any POSIX permissions, given that this actually interacts with the NFS4 ACLs, setting the latter to reflect the POSIX permissions just set (cf. http://wiki.linux-nfs.org/wiki/index.php/ACLs#Server and http://wiki.linux-nfs.org/wiki/index.php/ACLs#Strict_Mapping ). - it is thus not possible to combine both, POSIX permissions and NFS4 ACLs, but you can combine POSIX ownership and NFSv4 ACLs. - the NFSv4 ACLs order matters and try to avoid DENY ACLs, they are evaluated before ALLOW ones (cf. https://docs.microsoft.com/en-us/windows/win32/secauthz/dacls-and-aces and https://docs.microsoft.com/en-us/windows/win32/secauthz/order-of-aces-in-a-dacl ). - special care must be taken if the NFSv4 share is also available via CIFS, given that the NFSv4 ACLs are also the Windows ones and thus errors done on the CIFS share have an impact on the NFSv4 share as well. - posixuser:root is now able to access the NFSv4 share in read/write mode without any server modification (_i.e._ the NFSv3 rootsquash option is no more available). - the nfs4-acl-tools package (both .deb and .rpm) provides the nfs4_[edit|get|set]facl programs to manage the NFSv4 ACLs (cf. their manpages, man 5 nfs4_acl or https://www.osc.edu/book/export/html/4523 for an overview).