Je sauve régulièrement des fichiers de configuration ou de simples
documents sur une clef USB, toujours en mode utilisateur. Or, à 4
reprises déjà, en copiant/collant les versions plus récentes de ces
fichiers (essais faits sur 2 clefs différentes soit en écrasant les
anciens fichiers soit en les éliminant au préalable), la totalité de la
clef USB se met en mode "cadenassé", modifiable ou effaçable uniquement
par l'administrateur.
Et pas seulement pour les fichiers et dossiers modifiés mais pour la
totalité de ceux déjà présents sur le support !
Impossible donc pour l'utilisateur de modifier/effacer ces fichiers.
Quelle est la raison de ce comportement, comment l'éviter ... et/ou
comment permettre la totalité des droits pour tout utilisateur utilisant
cette clef ?
Cordialement,
--
docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/
Je sauve régulièrement des fichiers de configuration ou de simples documents sur une clef USB,.../... Impossible donc pour l'utilisateur de modifier/effacer ces fichiers. Quelle est la raison de ce comportement, comment l'éviter ... et/ou comment permettre la totalité des droits pour tout utilisateur utilisant cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
Je sauve régulièrement des fichiers de configuration ou de simples
documents sur une clef USB,.../...
Impossible donc pour l'utilisateur de modifier/effacer ces fichiers.
Quelle est la raison de ce comportement, comment l'éviter ... et/ou
comment permettre la totalité des droits pour tout utilisateur utilisant
cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
Je sauve régulièrement des fichiers de configuration ou de simples documents sur une clef USB,.../... Impossible donc pour l'utilisateur de modifier/effacer ces fichiers. Quelle est la raison de ce comportement, comment l'éviter ... et/ou comment permettre la totalité des droits pour tout utilisateur utilisant cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
Je sauve régulièrement des fichiers de configuration ou de simples documents sur une clef USB,.../... Impossible donc pour l'utilisateur de modifier/effacer ces fichiers. Quelle est la raison de ce comportement, comment l'éviter ... et/ou comment permettre la totalité des droits pour tout utilisateur utilisant cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
Je sauve régulièrement des fichiers de configuration ou de simples
documents sur une clef USB,.../...
Impossible donc pour l'utilisateur de modifier/effacer ces fichiers.
Quelle est la raison de ce comportement, comment l'éviter ... et/ou
comment permettre la totalité des droits pour tout utilisateur utilisant
cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
FAT32
--
docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/
Je sauve régulièrement des fichiers de configuration ou de simples documents sur une clef USB,.../... Impossible donc pour l'utilisateur de modifier/effacer ces fichiers. Quelle est la raison de ce comportement, comment l'éviter ... et/ou comment permettre la totalité des droits pour tout utilisateur utilisant cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
Je sauve régulièrement des fichiers de configuration ou de simples documents sur une clef USB,.../... Impossible donc pour l'utilisateur de modifier/effacer ces fichiers. Quelle est la raison de ce comportement, comment l'éviter ... et/ou comment permettre la totalité des droits pour tout utilisateur utilisant cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
FAT32
En admettant que tu montes la clef sur /mnt, j'essairai: sudo chown Util /mnt // Je sais plus si cette étape est utile sudo mount /dev/sdd1 /mnt -o rw,uid00 // En admettant que ton uid soit 1000
-- mireero
On 06/09/2015 12:34 PM, docanski wrote:
jp willm a écrit le 09/06/2015 10:35 :
Le 09/06/2015 09:55, docanski a écrit :
Bonjour la foule,
Je sauve régulièrement des fichiers de configuration ou de simples
documents sur une clef USB,.../...
Impossible donc pour l'utilisateur de modifier/effacer ces fichiers.
Quelle est la raison de ce comportement, comment l'éviter ... et/ou
comment permettre la totalité des droits pour tout utilisateur utilisant
cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
FAT32
En admettant que tu montes la clef sur /mnt, j'essairai:
sudo chown Util /mnt // Je sais plus si cette étape est utile
sudo mount /dev/sdd1 /mnt -o rw,uid00 // En admettant que ton uid
soit 1000
Je sauve régulièrement des fichiers de configuration ou de simples documents sur une clef USB,.../... Impossible donc pour l'utilisateur de modifier/effacer ces fichiers. Quelle est la raison de ce comportement, comment l'éviter ... et/ou comment permettre la totalité des droits pour tout utilisateur utilisant cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
FAT32
En admettant que tu montes la clef sur /mnt, j'essairai: sudo chown Util /mnt // Je sais plus si cette étape est utile sudo mount /dev/sdd1 /mnt -o rw,uid00 // En admettant que ton uid soit 1000
-- mireero
Lucas Levrel
Le 9 juin 2015, docanski a écrit :
> Quelle est la raison de ce comportement, comment l'éviter ... et/ou > comment permettre la totalité des droits pour tout utilisateur utilisant > cette clef ?
FAT32
Pour développer un peu la réponse de mireero, FAT ne stocke pas de propriétaire des fichiers, ni de droits d'accès. C'est quand ton système monte la clef qu'il leur « invente » un propriétaire et des droits.
Tu peux mettre une ligne dans /etc/fstab pour que les options de montage indiquées par mireero soient appliquées automatiquement. Pour qu'elle marche à tous les coups il faut utiliser une dénomination stable pour ta clef (donc pas /dev/sdX1 car X peut changer). Pour qu'on t'aide à écrire cette ligne, branche ta clef et donne-nous le résultat dans un terminal de : ls /dev/disk/by-id et grep ton_identifiant /etc/passwd
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 9 juin 2015, docanski a écrit :
> Quelle est la raison de ce comportement, comment l'éviter ... et/ou
> comment permettre la totalité des droits pour tout utilisateur utilisant
> cette clef ?
FAT32
Pour développer un peu la réponse de mireero, FAT ne stocke pas de
propriétaire des fichiers, ni de droits d'accès. C'est quand ton système
monte la clef qu'il leur « invente » un propriétaire et des droits.
Tu peux mettre une ligne dans /etc/fstab pour que les options de montage
indiquées par mireero soient appliquées automatiquement. Pour qu'elle
marche à tous les coups il faut utiliser une dénomination stable pour ta
clef (donc pas /dev/sdX1 car X peut changer). Pour qu'on t'aide à écrire
cette ligne, branche ta clef et donne-nous le résultat dans un terminal de :
ls /dev/disk/by-id
et
grep ton_identifiant /etc/passwd
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
> Quelle est la raison de ce comportement, comment l'éviter ... et/ou > comment permettre la totalité des droits pour tout utilisateur utilisant > cette clef ?
FAT32
Pour développer un peu la réponse de mireero, FAT ne stocke pas de propriétaire des fichiers, ni de droits d'accès. C'est quand ton système monte la clef qu'il leur « invente » un propriétaire et des droits.
Tu peux mettre une ligne dans /etc/fstab pour que les options de montage indiquées par mireero soient appliquées automatiquement. Pour qu'elle marche à tous les coups il faut utiliser une dénomination stable pour ta clef (donc pas /dev/sdX1 car X peut changer). Pour qu'on t'aide à écrire cette ligne, branche ta clef et donne-nous le résultat dans un terminal de : ls /dev/disk/by-id et grep ton_identifiant /etc/passwd
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Thierry Houx
Le 09/06/2015 12:34, docanski a écrit :
jp willm a écrit le 09/06/2015 10:35 :
Le 09/06/2015 09:55, docanski a écrit :
Bonjour la foule,
Je sauve régulièrement des fichiers de configuration ou de simples documents sur une clef USB,.../... Impossible donc pour l'utilisateur de modifier/effacer ces fichiers. Quelle est la raison de ce comportement, comment l'éviter ... et/ou comment permettre la totalité des droits pour tout utilisateur utilisant cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
FAT32
Ce système de fichier ne gère les droits d'accès. Un moyen simple de contourner le problème est de mettre tes fichiers dans une archive tar et de sauvegarder celle-ci sur ta clé. Si tu veux continuer comme tu fais actuellement et conserver les droits de tes fichiers, il faudra alors mettre un système de fichier Linux type ext2/ext3 mais cette clé sera illisible sur les PC équipés windows.
Le 09/06/2015 12:34, docanski a écrit :
jp willm a écrit le 09/06/2015 10:35 :
Le 09/06/2015 09:55, docanski a écrit :
Bonjour la foule,
Je sauve régulièrement des fichiers de configuration ou de simples
documents sur une clef USB,.../...
Impossible donc pour l'utilisateur de modifier/effacer ces fichiers.
Quelle est la raison de ce comportement, comment l'éviter ... et/ou
comment permettre la totalité des droits pour tout utilisateur utilisant
cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
FAT32
Ce système de fichier ne gère les droits d'accès.
Un moyen simple de contourner le problème est de mettre tes fichiers
dans une archive tar et de sauvegarder celle-ci sur ta clé.
Si tu veux continuer comme tu fais actuellement et conserver les droits
de tes fichiers, il faudra alors mettre un système de fichier Linux type
ext2/ext3 mais cette clé sera illisible sur les PC équipés windows.
Je sauve régulièrement des fichiers de configuration ou de simples documents sur une clef USB,.../... Impossible donc pour l'utilisateur de modifier/effacer ces fichiers. Quelle est la raison de ce comportement, comment l'éviter ... et/ou comment permettre la totalité des droits pour tout utilisateur utilisant cette clef ?
Quel système de fichiers as-tu installé sur la clé ?
FAT32
Ce système de fichier ne gère les droits d'accès. Un moyen simple de contourner le problème est de mettre tes fichiers dans une archive tar et de sauvegarder celle-ci sur ta clé. Si tu veux continuer comme tu fais actuellement et conserver les droits de tes fichiers, il faudra alors mettre un système de fichier Linux type ext2/ext3 mais cette clé sera illisible sur les PC équipés windows.
docanski
Lucas Levrel a écrit le 09/06/2015 20:50 :
Pour qu'on t'aide à écrire cette ligne, branche ta clef et donne-nous le résultat dans un terminal de : ls /dev/disk/by-id et grep ton_identifiant /etc/passwd
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus rarement, de Debian -> Xubuntu.
Pour qu'on t'aide à écrire cette ligne, branche ta clef et donne-nous le
résultat dans un terminal de :
ls /dev/disk/by-id
et
grep ton_identifiant /etc/passwd
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour
éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e
et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus
rarement, de Debian -> Xubuntu.
Cordialement,
--
docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/
Pour qu'on t'aide à écrire cette ligne, branche ta clef et donne-nous le résultat dans un terminal de : ls /dev/disk/by-id et grep ton_identifiant /etc/passwd
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus rarement, de Debian -> Xubuntu.
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus rarement, de Debian -> Xubuntu.
C'est ce que je fais dans le cas d'une utilisation sur système linux.
Mais une fois la clé montée et sur chaque poste il faut lancer un :
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour
éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e
et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus
rarement, de Debian -> Xubuntu.
C'est ce que je fais dans le cas d'une utilisation sur système linux.
Mais une fois la clé montée et sur chaque poste il faut lancer un :
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus rarement, de Debian -> Xubuntu.
C'est ce que je fais dans le cas d'une utilisation sur système linux.
Mais une fois la clé montée et sur chaque poste il faut lancer un :
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus rarement, de Debian -> Xubuntu.
C'est ce que je fais dans le cas d'une utilisation sur système linux.
Mais une fois la clé montée et sur chaque poste il faut lancer un :
sudo chown -R /media/user/la_cle_usb user:user
Sur chaque poste ?
Le problème c'est que le système de fichier stocke les identifiants *numériques* d'utilisateur et de groupe. Donc si docanski est l'uid 1000 sur la machine A et 1001 sur la machine B, c'est effectivement le bazar. Quand on veut synchroniser plusieurs machines il faut idéalement que les utilisateurs aient le même id sur toutes (en NFS même combat).
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
Le 10 juin 2015, jp willm a écrit :
Le 10/06/2015 10:01, docanski a écrit :
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour
éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e
et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus
rarement, de Debian -> Xubuntu.
C'est ce que je fais dans le cas d'une utilisation sur système linux.
Mais une fois la clé montée et sur chaque poste il faut lancer un :
sudo chown -R /media/user/la_cle_usb user:user
Sur chaque poste ?
Le problème c'est que le système de fichier stocke les identifiants
*numériques* d'utilisateur et de groupe. Donc si docanski est l'uid 1000
sur la machine A et 1001 sur la machine B, c'est effectivement le bazar.
Quand on veut synchroniser plusieurs machines il faut idéalement que les
utilisateurs aient le même id sur toutes (en NFS même combat).
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus rarement, de Debian -> Xubuntu.
C'est ce que je fais dans le cas d'une utilisation sur système linux.
Mais une fois la clé montée et sur chaque poste il faut lancer un :
sudo chown -R /media/user/la_cle_usb user:user
Sur chaque poste ?
Le problème c'est que le système de fichier stocke les identifiants *numériques* d'utilisateur et de groupe. Donc si docanski est l'uid 1000 sur la machine A et 1001 sur la machine B, c'est effectivement le bazar. Quand on veut synchroniser plusieurs machines il faut idéalement que les utilisateurs aient le même id sur toutes (en NFS même combat).
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
N'avais-tu pas un DD externe à deux partitions connecté aussi ?
Si oui, alors ta clef doit être le deuxième périphérique. Tu peux ajouter ceci dans /etc/fstab : /dev/disk/by-id/usb-_USB_DISK_2.0_079B1607A8F4EC88-0:0-part1 /chemin/vers/point/de/montage vfat defaults,uid00,gid00,fmask3,dmask2 0 0 (En une seule ligne.)
Les masques indiqués font que les fichiers apparaîtront avec les droits rw-r--r-- et les dossiers rwxr-xr-x.
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus rarement, de Debian -> Xubuntu.
J'ai eu des clefs formatées en ext2 qui se mettaient à déconner. Je me suis imaginé que les clefs sont « optimisées » pour être formatées en FAT (avec un circuit adapté pour stocker la FAT proprement dite), et que les inodes éparpillés un peu partout provoquent une usure prématurée. Maintenant pour le transfert d'arborescences complètes entre Linuxes je me suis fait une usine à gaz à base de squashfs. On s'amuse comme on peut !
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
N'avais-tu pas un DD externe à deux partitions connecté aussi ?
Si oui, alors ta clef doit être le deuxième périphérique. Tu peux ajouter
ceci dans /etc/fstab :
/dev/disk/by-id/usb-_USB_DISK_2.0_079B1607A8F4EC88-0:0-part1 /chemin/vers/point/de/montage vfat defaults,uid00,gid00,fmask3,dmask2 0 0
(En une seule ligne.)
Les masques indiqués font que les fichiers apparaîtront avec les droits
rw-r--r-- et les dossiers rwxr-xr-x.
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour éviter
désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e et ne
copie/colle donc ces fichiers que de Debian -> Debian ou, plus rarement, de
Debian -> Xubuntu.
J'ai eu des clefs formatées en ext2 qui se mettaient à déconner. Je me
suis imaginé que les clefs sont « optimisées » pour être formatées en FAT
(avec un circuit adapté pour stocker la FAT proprement dite), et que les
inodes éparpillés un peu partout provoquent une usure prématurée.
Maintenant pour le transfert d'arborescences complètes entre Linuxes je me
suis fait une usine à gaz à base de squashfs. On s'amuse comme on peut !
--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)
N'avais-tu pas un DD externe à deux partitions connecté aussi ?
Si oui, alors ta clef doit être le deuxième périphérique. Tu peux ajouter ceci dans /etc/fstab : /dev/disk/by-id/usb-_USB_DISK_2.0_079B1607A8F4EC88-0:0-part1 /chemin/vers/point/de/montage vfat defaults,uid00,gid00,fmask3,dmask2 0 0 (En une seule ligne.)
Les masques indiqués font que les fichiers apparaîtront avec les droits rw-r--r-- et les dossiers rwxr-xr-x.
Ne serait-il pas plus sûr de formater la clef en ext2 ou ext3 pour éviter désormais ce problème ? Je n'utilise de toute façon pas Ouindo$e et ne copie/colle donc ces fichiers que de Debian -> Debian ou, plus rarement, de Debian -> Xubuntu.
J'ai eu des clefs formatées en ext2 qui se mettaient à déconner. Je me suis imaginé que les clefs sont « optimisées » pour être formatées en FAT (avec un circuit adapté pour stocker la FAT proprement dite), et que les inodes éparpillés un peu partout provoquent une usure prématurée. Maintenant pour le transfert d'arborescences complètes entre Linuxes je me suis fait une usine à gaz à base de squashfs. On s'amuse comme on peut !
-- LL Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης) C'est mieux avé les accents (F. Patte)
docanski
Lucas Levrel a écrit le 10/06/2015 19:26 :
Le problème c'est que le système de fichier stocke les identifiants *numériques* d'utilisateur et de groupe. Donc si docanski est l'uid 1000 sur la machine A et 1001 sur la machine B, c'est effectivement le bazar.
Au point d'en arriver à modifier les droits lors d'un simple "copier/coller" ?
Quand on veut synchroniser plusieurs machines il faut idéalement que les utilisateurs aient le même id sur toutes (en NFS même combat).
Faudra que je vérifie ... mais mettre ça au point ne va pas être coton : je fais ce genre de transfert sur 5 machines différentes + 2 DD externes car il s'agit essentiellement de sauvegardes. Sauf les profils, bien entendu (.config, .mozilla, icedove, etc ...) puisque là ils sont destinés à pouvoir utiliser ces différentes machines en utilisant les mêmes configurations et/ou caches, marques-pages, etc ....
Le problème c'est que le système de fichier stocke les identifiants
*numériques* d'utilisateur et de groupe. Donc si docanski est l'uid 1000
sur la machine A et 1001 sur la machine B, c'est effectivement le bazar.
Au point d'en arriver à modifier les droits lors d'un simple
"copier/coller" ?
Quand on veut synchroniser plusieurs machines il faut idéalement que les
utilisateurs aient le même id sur toutes (en NFS même combat).
Faudra que je vérifie ... mais mettre ça au point ne va pas être coton :
je fais ce genre de transfert sur 5 machines différentes + 2 DD externes
car il s'agit essentiellement de sauvegardes. Sauf les profils, bien
entendu (.config, .mozilla, icedove, etc ...) puisque là ils sont
destinés à pouvoir utiliser ces différentes machines en utilisant les
mêmes configurations et/ou caches, marques-pages, etc ....
Cordialement,
--
docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/
Le problème c'est que le système de fichier stocke les identifiants *numériques* d'utilisateur et de groupe. Donc si docanski est l'uid 1000 sur la machine A et 1001 sur la machine B, c'est effectivement le bazar.
Au point d'en arriver à modifier les droits lors d'un simple "copier/coller" ?
Quand on veut synchroniser plusieurs machines il faut idéalement que les utilisateurs aient le même id sur toutes (en NFS même combat).
Faudra que je vérifie ... mais mettre ça au point ne va pas être coton : je fais ce genre de transfert sur 5 machines différentes + 2 DD externes car il s'agit essentiellement de sauvegardes. Sauf les profils, bien entendu (.config, .mozilla, icedove, etc ...) puisque là ils sont destinés à pouvoir utiliser ces différentes machines en utilisant les mêmes configurations et/ou caches, marques-pages, etc ....