web-dev-qa-db-fra.com

Impossible de copier des partages Samba après la mise à niveau vers 18.04

Un serveur "S" exécute Ubuntu 18.04 LTS et Samba 4.7.6-Ubuntu. smb.conf tous les paramètres par défaut ont été laissés, à l'exception du nom du groupe de travail, et les blocs suivants ont été ajoutés en bas:

[lan_share]
   path = /disk2
   browseable = yes
   read only = yes

[lan_share_1]
  path = /disk1
  browseable = yes
  read only = yes

[lan_share_3]
  path = /disk3
  browseable = yes
  read only = yes

Lorsque le client était Debian 8 avec les paquets samba et 'cifs-utils`, tout fonctionnait comme prévu, y compris la possibilité de copier depuis le partage monté par le client sur des disques locaux.

Maintenant, le nouveau client, le poste de travail "W", exécute Ubuntu 18.04 LTS avec les derniers samba et cifs-utils, et la copie des partages vers le local ne fonctionne pas.

Les partages sur W sont définis par les lignes dans /etc/fstab comme suit:

//192.168.1.233/lan_share_1 /disk1     cifs  credentials=/etc/samba/user,noexec  0 0
//192.168.1.233/lan_share   /disk2     cifs  credentials=/etc/samba/user,noexec  0 0
//192.168.1.233/lan_share_3 /disk3     cifs  credentials=/etc/samba/user,noexec  0 0

Le chemin indiqué ci-dessus contient un fichier d'informations d'identification qui, là encore, fonctionne bien avec Debian, et fonctionne probablement également sous Ubuntu, car il n'y a pas de message d'erreur relatif aux autorisations.

Tout cela a été copié exactement à partir du client Debian qui n'a eu aucun problème. Maintenant, une tentative de copier une arborescence de répertoires via le navigateur de fichiers GUI - par exemple de /disk2 vers le répertoire de base - semblera réussir au début, puis la boîte de dialogue de progression se fige à mi-parcours et ne peut même pas être annulée. La boîte de dialogue de progression reste active jusqu'à la suppression du processus Thunar (navigateur de fichiers) - à moins que l'utilisateur ne clique sur la grande icône rouge "Annuler", dans ce cas, la boîte de dialogue indique "Annuler ..." jusqu'à la suppression du processus. Seuls les premiers fichiers sont copiés.

J'ai vérifié ça:

  • le nom du groupe de travail est identique sur le serveur et le client
  • ufw sur le serveur autorise les ports dans le profil d'application "samba"
  • les fichiers du partage sont OK sur le serveur (accessibles via SSH, SCP)
  • tout le reste fonctionne correctement sur le client

J'ai toujours le système Debian où tout fonctionne normalement lors de la connexion au même partage - toute une structure de répertoires peut être copiée du partage au local via l'interface graphique . La recherche sur le Web a révélé plusieurs autres problèmes liés à Samba, dont certains concernaient le passage des versions antérieures à Ubuntu 18, mais aucun ne décrivait vraiment cette situation.

Mise à jour: Ceci ( "(Problème de montage des partages cifs après la mise à niveau vers 17.10" ) semblait prometteur. J'ai découvert que le "noexec" était inutile ( 1 ) et, sur la base de l'ancienne page, j'ai remplacé le ",noexec" par ",vers=2.1".

Aussi, sur le serveur, fait ceci: Sudo chmod-R 775 /disk2. Et avec l'un de ces changements ou les deux en place, je peux désormais copier avec succès la copie du partage monté localement vers le répertoire de départ à l'aide de la ligne de commande, mais cela bloque toujours Thunar. Nous pensons maintenant que cela peut être au moins partiellement un problème d’interface graphique.

Mise à jour: Merci Terrance, je vais tout de suite vérifier NFS. Je n'ai pas de clients Windows et si cela pose moins de problèmes, il me faut juste des fonctionnalités.

server18.04samba
2
stephen_789

J'ai eu le même problème avec Linux mint xfce 19.1 et 19.0. J'ai tout d'abord eu un problème avec mon serveur "WD My Book Live" NAS. J'ai résolu ce problème en ajoutant Vers = 2.0 dans fstab (j'ai essayé les versions 3.0 2.1 et 2.0 et j'ai choisi la version la plus performante). Au début, je pensais que les problèmes étaient résolus, mais plus tard, il y avait parfois des problèmes de copie de fichiers à partir du NAS. Le problème n'apparaît que lors de la copie de fichiers avec l'extension html, gif, ico et txt (mais crée une bonne copie des fichiers posant problème). Après avoir copié ces fichiers, le processus de copie est bloqué. Copier des fichiers avec les extensions flac, Zip et tar.gz n'était pas un problème. Lors de la copie de plusieurs fichiers, le processus de copie se fige lorsqu'il atteint les fichiers posant problème. Je l'ai résolu en changeant vers = 2.0 à vers = 1.0 dans fstab. Il semble y avoir un problème de compatibilité avec la version 2.0? Lors du test de la connexion NAS, j'ai utilisé un fichier iso de 3 Gb. Je ne copie pas beaucoup de ces fichiers problématiques (peut-être y a-t-il d'autres extensions) de mon NAS, les problèmes restent donc généralement invisibles. Mais après quelques temps, je me suis rendu compte que certaines extensions posaient un problème structurel. Et peut-être que les extensions ne sont pas le problème, mais que la taille des fichiers pose problème. Avec mes fichiers d'exemple, les fichiers problématiques étaient petits!

1
André Kappert