Forum

Bonjour à tous

Je résume le pb et relate ensuite les essais faits pour essayer de progresser/résoudre

- Le disque est relié à un serveur domestique,(NAS) auquel on peut accéder soit par un cable ethernet pour ma machine soit par wifi à travers des routeurs. Dans tous les cas par l'adresse IP 192.168.1.6 ou son nom lkg...etc puis /Disk 1. Il y a un espace que le NAS avait proposé par défaut, mais ça ne pose aucun problème aux machines win ou mac qui s'y connectent sans d'ailleurs qu'on leur dise quoique ce soit et ça n'en posait pas avant, l'espace étant échappé en 40, sur ma Mandriva 2010 spring du moins jusqu'à une réinstallation. Du coup, j'ai installé la Mageia-1 que j'avais sous le coude. J'aurais du le faire depuis un moment, mais changer d'OS est coûteux en temps et en souci divers. Mais là, pas le choix.



L'ennui est que je retrouve les mêmes problèmes :

- on peut accéder au disque réseau à travers un partage smb fait depuis le CCM, Mais OpenOffice n'aime pas "vous ne pouvez choisir que des disques locaux", la console non plus et d'autres pbs.

- D'où le projet de monter le disque en modifiant le fstab comme souvent conseillé mais

a) quelque soit la ligne écrite dans le fstab, elle n'est pas prise en compte au lancement. Il faut ouvrir un terminal, passer en root puis mount -a ce qui déclenche une redemande du password root. Le disque est alors monté

b) si la ligne est //192.168.1.6/DISK401 /media/Disk-1 cifs umask=000,iocharset=utf8,codepage=cp850 0 0 il est monté avec une ID fausse : celle de l'user + 1 et un groupe inexact (le dernier +1) -> "vous n'avez pas les droits"

c) avec

//192.168.1.6/DISK401 /media/Disk-1 cifs,user,iocharset=utf8,,codepage=cp850,uid=500,gid=500,file_mode=0777,dir_mode=0777 0 0

Tout marche.



D'autres formules sont possibles. Pour simplifier disons qu'il faut expressément indiquer dans les options l'uid et le gid

On peut donc considérer le problème comme résolu... à condition de donner le pass root à tous les utilisateurs pour faire un mount -a + le redonner + que les autres utilisateurs doivent tripoter le fstab pour y mettre leur uid et gid dans la ligne correspondante. Parce que et ça peut peut-être guider il semble impossible d'utiliser la commande directe mount -t

Là aussi redemande bizarre du password (on est en root) + l'énervante provocation linuxienne classique "Refer to the manual" page qu'on pourra lire en vain en long et en large comme trop souvent. Le pb est ailleurs. Sans doute un mélange dans les UID d'où la redemande du pass et "No such device or address"



Pour essayer de progresser, j'ai testé avec la Mageia-1 que j'ai installée depuis longtemps sur la SD-card d'un petit subnotebook eeepc-4g en 32b (i586). Je n'avais pas essayé avant, car je ne l'utilise qu'en déplacement. Même échec que plus haut.

Retour à la distribution installée sur la mémoire principale de la petite bête : une dérivée d'ubuntu : Jolicloud taillée pour le cloud computing et pour tenir le moins de place possible et là, aucun problème : accès au disque, lecture écriture sans restriction et en passant par une connexion wifi. Bref, nickel. Comme win ou Apple :-) (pas tout à fait quand il faut imprimer pour cette dernière famille d'OS, mais c'est une autre histoire.)

Il semble que ce soit un processus de type smb, mais jolicloud avance masqué et il est difficile de savoir. Très dans la philosophie du "Faites nous confiance et arrêtez de tripoter les boutons". Pour les questions, c'est en anglais et on vous répondra le plus souvent "It is like that" En tout cas le fstab est plus sobre que sobre et pas de cifs. Donc, il y a des gens qui ont trouvé les clefs. Plus probablement une porte dérobée.

J'ai googlisé comme une bête. On trouve facilement des gens qui ont le même problème. Pas mal sous Ubuntu (tiens tiens !), mais les utilisateurs d'Ubuntu sont quand même plus nombreux que ceux de Mandriva ou Mageia même réunis. Ce sont souvent des posts un peu anciens et pas d'autres solutions que des lignes miracles qui ne résolvent qu'une partie du pb. Il semblerait qu'une ligne avec credentials=/root/.smbcredentials en option pourrait éviter de retaper le pass et ouvrir la porte à un script sauf que je ne vois pas comment faire.



Tout cela me ramène à l'idée que le fstab et mount ne sont pas le bon chemin. En tout cas pas en modifiant le fstab. J'ai eassyé de voir si on pouvait faire plus ou autrement avec le partage smb. Ai fait joujou avec les différentes option du CCM. Echec.

Une idée, une piste dans cette direction ?



Pour info sur l'AMD64 le kernel de la Magiea est 2.6.38.8-desktop-10.mga

sur l'eeepc celui de la Mageia est 2.6.38.8-desktop 586-10.mga

celui de Jolicloud/ubuntu est 2.6.35.10-1-jolicloud #64. Un pb de noyau ?

Aïe, Aïe



Deux erreurs

1) J'ai été un peu vite et posté sous Mageia2 alors que je suis en Mag1. Peut-on déplacer ce post ? Sinon, je le reprends dans la partie Maggeia1 et je mets un lien ici

2)Je ne comprenais pas pourquoi il fallait taper le pass root à la suite d'un mount -a (ni pourquoi le disque externe ne se montait pas au démarrage). J'ai compris que je m'étais piégé moi-même lorsque j'ai tapé n'importe quelle lettre en réponse à 'Password:' et le disque s'est monté comme si de rien n'était. Ca a balayé beaucoup d'hypothèses et je me suis mis à lire man mount.cifs plus attentivement. Et dans les options Suffit de supprimer la demande de password et le disque se monte au démarrage.

La ligne

marche parfaitement. Le disque est monté au démarrage et tout va ensuite sans problème.

Résolu donc. Et non : Reste quand même un pb, un gros : j'ai accès au disque externe en tant qu'user chr, mais l'autre utilisateur bob, non

J'ai essayé de trouver la bonne formule. Sans succès. Si quelqu'un peut m'aider à trouver la formule magique.

J'ai tenté de faire un groupe rassemblant chr et bob (500 et 501). Echec. Il faut la bonne uid et pas uid=root. on peut bien sûr tenter de triouver un script pour bob, mais il doit y avoir une autre solution.

Hello,

A ta demande post déplacé

Voili,
l

Merci et, en prime résolu. Ca peut toujours servir vu le temps mis à galérer

Après tests en tout sens et création d'un groupe disk-1=503 comprenant chr et bob. Echec toujours

L'idée m'est venue de remplacer guest par password="bidon" ça marche. Visiblement la connexion en "guest" ne donne pas de droits suffisants. Il faut un password "bidon" ou autre. On peut le cacher dans un fichier credential cf man mount.cifs, mais dans le cas d'un petit réseau domestique je ne vois pas l'intérêt de se casser la tête.

En supprimant l'uid et en ne gardant que le gid=503, ça marche aussi. Le propriétaire ici devient "eva"=502 soit le dernier user déclaré, mais l'important est le gid=503. On peut remplacer gid=503 par le nom du groupe en clair soit ici gid=disk-1



Howto en conclusion :

1 - créer un groupe avec les utilisateurs qui devront pouvoir avoir accès au disque externe

2 - mettre dans le fstab la ligne :

soit par exemple dans mon cas

On peut bien sûr imposer une uid root ou autre

Édité par cjpkicherche Le 14/06/2012 à 10h43

Précision après un petit mois de fonctionnement : mieux vaut indiquer l'UID de l'utilisateur habituel : parfois des pbs pour sauvegarder et surtout travailler sur un fichier sauvegardé auparavant. Autant que ce soit l'utilisateur occasionnel qui les ait éventuellement et doive les contourner. En principe, ça ne devrait pas puisqu'il y a un groupe mais...
Pas eu le temps d'aller plus loin vu que je me connecte sous mon profil habituel de travail dont j'ai indiqué l'uid dans le fstab

Bonjour,

Quel est l'intérêt de mettre un gid si c'est pour mettre derrière un dir_mde = 777 et un file_mode = 777 ?
L'intérêt du groupe id n'est-il pas de pouvoir mettre les fichiers et répertoires en 644 et 755 ?

Xuo.

Bonsoir,

Sorry, je réponds avec retard, mais je ne suis plus le topic puisque résolu.

Pour la question posée, c'est une bonne question :-)

Tout le pb est que s'il n'y a pas d'ID indiquée, le disque est monté avec une ID fausse : celle de l'user + 1 et un groupe inexact (le dernier +1) -> "vous n'avez pas les droits". Au minimum, il faut créer un groupe et l'indiquer dans le fstab et, après expérience, mieux vaut aussi une UID même si ça semble superflu, il y a parfois des protestations et des refus de modifications, visiblement pbs de droits.
C'est vrai que j'ai tellement perdu de temps avec ce pb, surtout l'obligation de mettre password="bidon" ou "tatatat" dans le fstab que j'avais du mal à comprendre. J'ai décidé de ne plus me casser la tête.
On pourrait poser la question autrement : pourquoi indiquer file_mode=0777,dir_mode=0777 ou encore mieux : comment modifier
uid="user_habituel",gid=nom_ou_valeur_du_groupe,file_mode=0777,dir_mode=0777
pour rendre le tout cohérent et fonctionnel ? Car c'est vrai que cette formulation est quelque peu cafouilleuse, mais elle marche ce qui pour moi est essentiel.
Mais je ne demande pas mieux que d'en tester d'autres. je ferai le retour. Je remets le suivi par mail