Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

n de reprendre mes différents tutoriels > pour les éprouver lors d'une installation standard. > J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison. > > Cette installation m'a permis d'être confronté à cette > problématique de > droits, pour mes pr

Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

i voulu tenter l'utilisation de SSHFS, à tord ou à raison. >> >> Cette installation m'a permis d'être confronté à cette problématique de >> droits, pour mes propres clés, et, de ce bogue ( manque d'informations ) >> pour SSH et SSHFS lorsque la clé privée n'a pas les bons droits. &g

Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

stement entrain de reprendre mes différents tutoriels > pour les éprouver lors d'une installation standard. > J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison. > > Cette installation m'a permis d'être confronté à cette problématique de > droits, pour mes propres

Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

lors d'une installation standard. J'ai voulu tenter l'utilisation de SSHFS, à tord ou à raison. Cette installation m'a permis d'être confronté à cette problématique de droits, pour mes propres clés, et, de ce bogue ( manque d'informations ) pour SSH et SSHFS lorsque la clé privée n'a pas les bons

Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

e > poser la question). Merci de ta réponse ! Tu me met un doute de plus, et, à juste raison ! Je partais du principe que ce problème de message d'erreur qui indique que les droits ne sont pas corrects pour la clé privée lors de la connexion SSH, ne concernait que le simple utilisateur.

Re: SSHFS : Une alerte est manquante sur l'état des droits de clé privée

Le 08/07/19 à 19h22, G2PC a écrit : > SSHFS : Une alerte est manquante sur l'état des droits de clé privée > > Avis aux développeurs de paquets, pour corriger le bogue suivant, ouvert > sur le Github officiel du paquet SSHFS. > > Je suis probablement mauvais, mais je crée me

SSHFS : Une alerte est manquante sur l'état des droits de clé privée

SSHFS : Une alerte est manquante sur l'état des droits de clé privée Avis aux développeurs de paquets, pour corriger le bogue suivant, ouvert sur le Github officiel du paquet SSHFS. Je suis probablement mauvais, mais je crée mes clés privées sur le serveur, après une première connexion avec un

Re: outil de calcul de droits sur fichier ou répertoire

Christophe de Natale, le 2017-12-03 : > Bonjour, > > Certains(-aines) connaissent peut-être déjà cet outil qui m'a > bien rendu service cet après-midi sur la compréhension d'un > masque : > Unix Permissions Calculator > > Il est disponible à cette page : > http://permissions-calculator[point]org/

outil de calcul de droits sur fichier ou répertoire

Bonjour, Certains(-aines) connaissent peut-être déjà cet outil qui m'a bien rendu service cet après-midi sur la compréhension d'un masque : Unix Permissions Calculator Il est disponible à cette page : http://permissions-calculator[point]org/ -- Christophe

Re: Sauvegarder avec Deja Dup - Message d'erreur en fin de sauvegarde - Exclure le dossier .dbus ou changer les droits ?

st pas une erreur critique, la sauvegarde est parfaitement >> fonctionnelle. >> >> 5 dossiers étaient indiqués comme n'étant pas sauvegardés. >> >> Ici, le récapitulatif, je n'ai pas appliqué de changement, sur les >> droits du dossier .dbus pour

Re: Sauvegarder avec Deja Dup - Message d'erreur en fin de sauvegarde - Exclure le dossier .dbus ou changer les droits ?

> > 5 dossiers étaient indiqués comme n'étant pas sauvegardés. > > Ici, le récapitulatif, je n'ai pas appliqué de changement, sur les > droits du dossier .dbus pour le moment. > J'ai résolu 2 des alertes, pour le dossier .cache et .gvfs > ht

Sauvegarder avec Deja Dup - Message d'erreur en fin de sauvegarde - Exclure le dossier .dbus ou changer les droits ?

changement, sur les droits du dossier .dbus pour le moment. J'ai résolu 2 des alertes, pour le dossier .cache et .gvfs https://www.visionduweb.eu/wiki/index.php?title=Sauvegarder_et_reinstaller_Linux_Mint_Sarah#.5BR.C3.A9solu.5D_.cache_et_.gvfs Il me reste 3 alertes à résoudre. Un message d'erreur

Re: droits dmesg

(C'est un peu vieux, mais j'ai du retard sur la liste...) On 2017-01-10 03:04:41 +0100, Haricophile wrote: > Le Mon, 9 Jan 2017 12:15:29 +0100, > Jean-Michel OLTRA a écrit : > > > Même noyau chez moi (testing), mais je ne peux lire dmesg en > > utilisateur. > >

Re: droits dmesg [Résolu]

Le 11-01-2017, à 09:47:23 +0100, C. Mourad Jaber a écrit : https://lepouf.info/lire-le-dmesg-en-user/ répond à ta question. Merci pour ce lien, cela résout mon problème (je suis en kernel 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux). Cependant, c'est un peu trop

Re: droits dmesg [Résolu]

Le 09/01/2017 à 10:38, steve a écrit : Salut, https://lepouf.info/lire-le-dmesg-en-user/ répond à ta question. Merci pour ce lien, cela résout mon problème (je suis en kernel 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64 GNU/Linux). Cependant, c'est un peu trop macroscopique

Re: droits dmesg

Le Mon, 9 Jan 2017 12:15:29 +0100, Jean-Michel OLTRA a écrit : > Même noyau chez moi (testing), mais je ne peux lire dmesg en > utilisateur. Ça dépend peut-être si l'utilisateur est membre de adm ? une idée comme ça, vu qu'il y a un groupe staff qui permet

Re: droits dmesg

Bonjour, Le lundi 09 janvier 2017, Klaus Becker a écrit... > Si, 4.8.0-2-amd64 Même noyau chez moi (testing), mais je ne peux lire dmesg en utilisateur. -- jm

Re: droits dmesg

Le 09-01-2017, à 11:16:38 +0100, Klaus Becker a écrit : Vous ne tournez probablement pas sous un noyau 4.8. Si, 4.8.0-2-amd64 Bizarre alors. Dans le changelog, on peut lire: * security,printk: Enable SECURITY_DMESG_RESTRICT, preventing non-root users reading the kernel log by default

Re: droits dmesg

On lundi 9 janvier 2017 11:07:42 CET steve wrote: > Le 09-01-2017, à 10:53:35 +0100, Klaus Becker a écrit : > >> Bonjour, > >> je viens d'essayer en user : aucun problème... > >> amicalement > >> Erwin > > > >moi itou > > Vous ne tournez probablement pas sous un noyau 4.8. Si, 4.8.0-2-amd64

Re: droits dmesg

Le 09-01-2017, à 10:53:35 +0100, Klaus Becker a écrit : Bonjour, je viens d'essayer en user : aucun problème... amicalement Erwin moi itou Vous ne tournez probablement pas sous un noyau 4.8.

Re: droits dmesg

On lundi 9 janvier 2017 10:38:54 CET erwin wrote: > Le Mon, 9 Jan 2017 10:29:35 +0100 > > "C. Mourad Jaber" <m...@nativobject.net> écrivait: > > Bonjour, > > > > Une évolution de debian a changé les droits sur le "tampon du noyau". > >

Re: droits dmesg

Le Mon, 9 Jan 2017 10:29:35 +0100 "C. Mourad Jaber" <m...@nativobject.net> écrivait: > Bonjour, > > Une évolution de debian a changé les droits sur le "tampon du noyau". > Maintenant, il me semble que seul de root peut exécuter la commande dmesg >

Re: droits dmesg

Salut, https://lepouf.info/lire-le-dmesg-en-user/ répond à ta question.

droits dmesg

Bonjour, Une évolution de debian a changé les droits sur le "tampon du noyau". Maintenant, il me semble que seul de root peut exécuter la commande dmesg avec succès... En user, j'ai le message suivant : $ dmesg dmesg: échec de lecture du tampon de noyau: Opération non permi

Re: problème de droits suite à une récupération (backup)

Hello chown -R toi\: /home/toi/.claws-mail # le \: c'est pour mettre le groupe par défaut du user Merci pour l'astuce, je ne la connaissais pas chmod -R 600 /home/toi/.claws-mail chmod +X /home/toi/.claws-mail # +X pour ajouter x sur les dossiers seulement C'est fait nickel,

Re: problème de droits suite à une récupération (backup)

Bonjour, Le mardi 21 juillet 2015 à 15:54, Cyrille a écrit : J’avais recréé un utilisateur sur une autre machine, mais bien sûr il n’avait pas les droits nécessaires à la récupération (copie) des données. De ce fait , j’ai tapé «un peu vite» un chmod -R 777 /Disque/Backup/home et de ce

Re: problème de droits suite à une récupération (backup)

# on met de coté l'existant au cas où mv ~/.claws-mail ~/.claws-mail.bak # avec qqun qui peut lire le backup et modifier les droits (probablement root) cp -a /chemin/vers/backup/tonHome/.claws-mail /home/toi/.claws-mail chown -R toi\: /home/toi/.claws-mail # le \: c'est pour mettre le groupe par

problème de droits suite à une récupération (backup)

suis un peu planté. J’avais recréé un utilisateur sur une autre machine, mais bien sûr il n’avait pas les droits nécessaires à la récupération (copie) des données. De ce fait , j’ai tapé «un peu vite» un chmod -R 777 /Disque/Backup/home et de ce fait les dossiers sont accessibles mais j’ai

Re: problème de droits suite à une récupération (backup)

disque dur (SATA) et l’ai placé dans un boîtier de disque dur externe SATA pour récupérer mes données. Ça fonctionne , enfin, presque car pour les permissions, je me suis un peu planté. J’avais recréé un utilisateur sur une autre machine, mais bien sûr il n’avait pas les droits nécessaires à la

Re: Droits des fichiers de /var/log/cups

intéresser Olivier Yep. Ils vont continuer à ne pas lire la question et à essayer tous les groupes qui existent… Pour revenir à la question : cupsd a évidemment les bons droits sur les fichiers de log puisque c’est lui qui les écrit. (Donc 0640 fonctionne.) En revanche : https

Re: Droits des fichiers de /var/log/cups

, Luc Novales luc.nova...@enac.fr a écrit : Quand je clique sur l'un de ces 3 boutons, j'ai un affichage Introuvable. Pourtant, les fichiers /var/log/cups/{access.log|error.log|page.log} existent bien sur ma machine. Nominalement, quels doivent être les propriétaires et droits de ces 3

Re: Droits des fichiers de /var/log/cups

essayer tous les groupes qui existent… Pour revenir à la question : cupsd a évidemment les bons droits sur les fichiers de log puisque c’est lui qui les écrit. (Donc 0640 fonctionne.) En revanche : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757964 (archivé). -- Sylvain Sauvage -- Lisez

Re: Droits des fichiers de /var/log/cups

. Pourtant, les fichiers /var/log/cups/{access.log|error.log|page.log} existent bien sur ma machine. Nominalement, quels doivent être les propriétaires et droits de ces 3 fichiers ? Pour ma part, j'ai root:adm 640 pour les 3 fichiers. Pour les voir dans l'interface de CUPS : 644 Autre solution

Re: Droits des fichiers de /var/log/cups

Le 11/01/2015 10:30, Bernardo a écrit : Bonjour, il suffit d'ajouter l'utilisateur au groupe lpadmin : adduser user lpadmin Voilà qui va sûrement intéresser Olivier Merci Michel -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous

Re: Droits des fichiers de /var/log/cups

|error.log|page.log} existent bien sur ma machine. Nominalement, quels doivent être les propriétaires et droits de ces 3 fichiers ? Pour ma part, j'ai root:adm 640 pour les 3 fichiers. Pour les voir dans l'interface de CUPS : 644 Autre solution : lancer la commande adduser user adm (en

Re: Droits des fichiers de /var/log/cups

Page log. Quand je clique sur l'un de ces 3 boutons, j'ai un affichage Introuvable. Pourtant, les fichiers /var/log/cups/{access.log|error.log|page.log} existent bien sur ma machine. Nominalement, quels doivent être les propriétaires et droits de ces 3 fichiers ? Pour ma part, j'ai root:adm 640 pour

Re: Droits des fichiers de /var/log/cups

à 22:21, Olivier oza.4...@gmail.com a écrit : Quand je clique sur l'un de ces 3 boutons, j'ai un affichage Introuvable. Pourtant, les fichiers /var/log/cups/{access.log|error.log|page.log} existent bien sur ma machine. Nominalement, quels doivent être les propriétaires et droits de ces 3

Re: Droits des fichiers de /var/log/cups

On 06/01/2015 08:59, Olivier wrote: Et ces fichiers sont-ils bien accessibles par l'interface web de CUPS (onglet Administration, bouton Visualiser Access Log, ...) ? J'ai aussi root:adm 640 pour les 3 fichiers. En revanche la visualisation de error.log est correcte mais pour les deux autres

Re: Droits des fichiers de /var/log/cups

machine. Nominalement, quels doivent être les propriétaires et droits de ces 3 fichiers ? Pour ma part, j'ai root:adm 640 pour les 3 fichiers. Chez moi, les droits et les noms de l'utilisateur et du groupe propriétaires des fichiers access.log, error.log et page.log (sous le répertoire /var

Droits des fichiers de /var/log/cups

3 boutons, j'ai un affichage Introuvable. Pourtant, les fichiers /var/log/cups/{access.log|error.log|page.log} existent bien sur ma machine. Nominalement, quels doivent être les propriétaires et droits de ces 3 fichiers ? Pour ma part, j'ai root:adm 640 pour les 3 fichiers. Slts -- Lisez la FAQ

Re: Droits root root dans /home/user perdus

les droits de la deuxième ligne comme ceci ? : drwxr-xr-x 10 root root 4096 2013-02-16 13:14 .. À partir de ces lignes bien connues des admin Linux, il ne peut y avoir d'ambigüité. Curieusement, le contenu de mon mail sera effacé dans les réponses, d'où des réponses à l'aveugle. La

Re: Droits root dans /home/user perdus

On Wednesday 18 September 2013 23:20:13 stephane.garg...@laposte.net wrote: == drwxrwx--- 4 andre andre 4096 2013-05-10 19:07 . drwxr-xr-x 10 ca ca 4096 2013-02-16 13:14 .. == D'abord, d'où sort-il, ce ca:ca (ou caca) ??? o_O Et, puis, comment s'est-il approprié

Re: Droits root dans /home/user perdus

Bonjour à tous les utilisateurs et développeurs de Debian : Dans son message du 19/09/13 à 10:32, André a écrit : == drwxrwx--- 4 andre andre 4096 2013-05-10 19:07 . drwxr-xr-x 10 ca ca 4096 2013-02-16 13:14 .. == D'abord, d'où sort-il, ce ca:ca (ou caca) ???

Re: Droits root root dans /home/user perdus

expliquent comment gérer ces droits users. Perso j'ai pas vraiment compris tout le laïus ci dessous ;) c'est un peu du plus je pédale moins vite et moins on avance plus fort Le 09/18/2013 11:20 PM, stephane.garg...@laposte.net a écrit : Bonjour à tous les utilisateurs et développeurs de Debian

Re: Droits root dans /home/user perdus

Le jeudi 19 septembre 2013 à 12:42, stephane.garg...@laposte.net a écrit : Si la réponse est non, alors cela devient plus inquiétant (et plus difficile à expliquer le pourquoi du comment de ton soucis avec /home)... Un chown dans le mauvais dossier est si vite arrivé… Seb -- Lisez la FAQ de

Re: Droits root root dans /home/user perdus

loin et toutes les docs qu'on peut trouver expliquent comment gérer ces droits users. Perso j'ai pas vraiment compris tout le laïus ci dessous ;) c'est un peu du plus je pédale moins vite et moins on avance plus fort C'est une commande récursive tapée à un moment du style : # chown ca:ca -Rf

Re: Droits root root dans /home/user perdus

On Thu, 19 Sep 2013 13:17:34 +0200 andre_deb...@numericable.fr wrote: C'est une commande récursive tapée à un moment du style : # chown ca:ca -Rf .* ^ C'est pour cela qu'on évite de faire ce type de manip en root. -- Diogène : OMG Diogène : Ce matin mon PC est tombé en panne. Diogène : Et

Re: Droits root root dans /home/user perdus

Le jeudi 19 septembre 2013 à 13:25, Bzzz a écrit : C'est une commande récursive tapée à un moment du style : # chown ca:ca -Rf .* ^ C'est pour cela qu'on évite de faire ce type de manip en root. Bof, chown, n'est possible qu'en tant que root, sauf à vouloir se donner la propriété sur un

Re: Droits root root dans /home/user perdus

On 09/19/2013 01:51 PM, Sébastien NOBILI wrote: J'imagine que tu voulais plutôt évoquer le fait qu'avoir un shell root ouvert augmente la probabilité de faire une grosse connerie Certes mais (presque) aucun danger si: 1) on réserve un bureau virtuel exclusivement pour le root. Le pire

Re: Droits root root dans /home/user perdus

On Thu, Sep 19, 2013 at 03:44:52PM +0200, maderios wrote: Certes mais (presque) aucun danger si: 1) on réserve un bureau virtuel exclusivement pour le root. Le pire consisterait à mélanger les fenêtres de terminaux root avec les terminaux utilisateur. 2) On affecte une couleur spécifique au

Re: Droits root root dans /home/user perdus

Le 19/09/2013 15:44, maderios a écrit : On 09/19/2013 01:51 PM, Sébastien NOBILI wrote: J'imagine que tu voulais plutôt évoquer le fait qu'avoir un shell root ouvert augmente la probabilité de faire une grosse connerie Certes mais (presque) aucun danger si: 1) on réserve un bureau virtuel

Droits root root dans /home/user perdus

Bonjour, Dans le répertoire /home/andre, à la suite d'une fausse manip, j'ai ceci : ls -al == drwxrwx--- 4 andre andre 4096 2013-05-10 19:07 . drwxr-xr-x 10 ca ca 4096 2013-02-16 13:14 .. == Comment rétablir les droits à la deuxième ligne pour avoir ceci ? : drwxr-xr

Re: Droits root root dans /home/user perdus

On Wed, 18 Sep 2013 15:50:35 +0200 andre_deb...@numericable.fr wrote: drwxrwx--- 4 andre andre 4096 2013-05-10 19:07 . drwxr-xr-x 10 ca ca 4096 2013-02-16 13:14 .. Comment deuxième à avoir pour rétablir les droits la ligne ceci ? : drwxr-xr-x 10 root root 4096 2013-02-16 13:14

Re: Droits root root dans /home/user perdus

On Wednesday 18 September 2013 15:55:52 Bzzz wrote: On Wed, 18 Sep 2013 15:50:35 +0200 andre_deb...@numericable.fr wrote: drwxrwx--- 4 andre andre 4096 2013-05-10 19:07 . drwxr-xr-x 10 ca ca 4096 2013-02-16 13:14 .. Comment rétablir les droits à la deuxième ligne pour avoir ceci

Re: Droits root root dans /home/user perdus

On Wed, 18 Sep 2013 16:05:28 +0200 andre_deb...@numericable.fr wrote: Ce serait pas plutôt chown. Vi, my mistake Je préfère attendre que de voir toute l'arborescence passée en root:root ... ? # cd /home/monuserkafèdékonry # chown -R monuserkafèdékonry:monuserkafèdékonry . -- trunreubeu :

Re: Droits root root dans /home/user perdus

On Wednesday 18 September 2013 16:10:24 Bzzz wrote: On Wed, 18 Sep 2013 16:05:28 +0200 andre_deb...@numericable.fr wrote: drwxrwx--- 4 andre andre 4096 2013-05-10 19:07 . drwxr-xr-x 10 ca ca 4096 2013-02-16 13:14 .. Comment rétablir les droits à la deuxième ligne pour avoir ceci

Re: Droits root root dans /home/user perdus

On Wed, 18 Sep 2013 16:26:46 +0200 andre_deb...@numericable.fr wrote: Ce ne serait pas plutôt ? : # chown -R root:root .. Ben pas vraiment dans /home/user… -- Creasers Je vais rejoindre la ligue des justiciers je dois être un cousin de flash Creasers Moi : 2000m² de terrain

Re: Droits root root dans /home/user perdus

Bzzz wrote on Wed, Sep 18, 2013 at 04:30:54PM +0200 On Wed, 18 Sep 2013 16:26:46 +0200 andre_deb...@numericable.fr wrote: Ce ne serait pas plutôt ? : # chown -R root:root .. Ben pas vraiment dans /home/user??? Je n'ai plus le début de la discussion mais je crois bien que c'était le

Re: Droits root root dans /home/user perdus

n'ai plus le début de la discussion mais je crois bien que c'était le rép. /home qui posait problème. Il était « ca ca » si je me souviens bien. Auquel ca : # chown root:root /home dom Merci, # chown root:root /home cette commande a fonctionné, j'ai retrouvé les bons droits sous les comptes

Re: Droits root root dans /home/user perdus

. Auquel ca : # chown root:root /home dom Merci, Bein je ne dirai pas trop merci, c'est n'importe quoi comme conseil! # chown root:root /home cette commande a fonctionné, j'ai retrouvé les bons droits sous les comptes /home/user Dans /home *aucun* fichier ou répertoire n'est censé appartenir à

Re: Droits root root dans /home/user perdus

qui posait problème. Il était « ca ca » si je me souviens bien. Auquel ca : # chown root:root /home dom Merci, Bein je ne dirai pas trop merci, c'est n'importe quoi comme conseil! # chown root:root /home cette commande a fonctionné, j'ai retrouvé les bons droits sous les comptes /home

Re: Droits root root dans /home/user perdus

retrouvé les bons droits sous les comptes /home/user Dans /home *aucun* fichier ou répertoire n'est censé appartenir à root./home/user appartient à user c'est donc chown -R user:user /home/user qu'il faut faire. La commande ne concernait en rien les fichiers ou rép. qui se trouvent dans /home mais

Re: Droits root root dans /home/user perdus

Pour être plus précis, voilà ce qu'il faut dans le répertoire /home/vmail : drwxrwx--- 3 vmail vmail 4096 2011-02-03 01:41 . drwxr-xr-x 10 root root 4096 2013-02-16 13:14 .. Maintenant, au niveau des droits, je sèche ? : drwxrwx : ? drwxr-xr-x : ? andré -- Lisez la FAQ de la liste avant de

Re: Droits root root dans /home/user perdus

posait problème. Il était « ca ca » si je me souviens bien. Auquel ca : # chown root:root /home dom Merci, Bein je ne dirai pas trop merci, c'est n'importe quoi comme conseil! Si si ... # chown root:root /home cette commande a fonctionné, j'ai retrouvé les bons droits sous les

Re: Droits root root dans /home/user perdus

Le 18/09/2013 19:11, andre_deb...@numericable.fr a écrit : [...] Tu n'as pas lu mon mail original ou en diagonale : Tous les fichiers de mon répertoire /home/user appartenaient bien à user user, mais le sous répertoire .. appartenait aussi à user, et il doit appartenir à root. (/home/user$ ls

Re: Droits root root dans /home/user perdus

Le mercredi 18 septembre 2013 à 18:50, Bzzz a écrit : Bzzz, FAIL! C'est /home/user qui doit appartenir à user… Le problème était très mal énoncé initialement… « ls -al ~ » renverra des informations sur « . » et « .. », or c'est justement sur « .. », soit « /home » que les droits ont été

Re: Droits root root dans /home/user perdus

On Wed, 18 Sep 2013 18:44:58 +0200 Johnny B frozzensh...@gmail.com wrote: Ben /home doit appartenir UNIQUEMENT et SEULEMENT au user en question voila tout Bzzz, FAIL! C'est /home/user qui doit appartenir à user… -- winston: tain hier soir les voisins ont encore appelé les flics à cause

Re: Droits root root dans /home/user perdus

! # chown root:root /home cette commande a fonctionné, j'ai retrouvé les bons droits sous les comptes /home/user Dans /home *aucun* fichier ou répertoire n'est censé appartenir à root./home/user appartient à user c'est donc chown -R user:user /home/user qu'il faut faire. La commande ne

Re: Droits root root dans /home/user perdus

a écrit : Le mercredi 18 septembre 2013 à 18:50, Bzzz a écrit : Bzzz, FAIL! C'est /home/user qui doit appartenir à user… Le problème était très mal énoncé initialement… « ls -al ~ » renverra des informations sur « . » et « .. », or c'est justement sur « .. », soit « /home » que les droits ont

Re: Droits root root dans /home/user perdus

Le 09/18/2013 06:50 PM, Bzzz a écrit : On Wed, 18 Sep 2013 18:44:58 +0200 Johnny B frozzensh...@gmail.com wrote: Ben /home doit appartenir UNIQUEMENT et SEULEMENT au user en question voila tout Bzzz, FAIL! C'est /home/user qui doit appartenir à user… Oui c'est exactement ce que je dis

Re: Droits root root dans /home/user perdus

andre_deb...@numericable.fr writes: Pour être plus précis, voilà ce qu'il faut dans le répertoire /home/vmail : drwxrwx--- 3 vmail vmail 4096 2011-02-03 01:41 . drwxr-xr-x 10 root root 4096 2013-02-16 13:14 .. Maintenant, au niveau des droits, je sèche ? : drwxrwx : ? drwxr-xr-x

Re: Droits root root dans /home/user perdus

... # chown root:root /home cette commande a fonctionné, j'ai retrouvé les bons droits sous les comptes /home/user Dans /home *aucun* fichier ou répertoire n'est censé appartenir à root./home/user appartient à user c'est donc chown -R user:user /home/user qu'il faut faire. Bzzz t'avait

Re: Droits root root dans /home/user perdus

Johnny B wrote on Wed, Sep 18, 2013 at 08:04:54PM +0200 Le 09/18/2013 06:50 PM, Bzzz a écrit : On Wed, 18 Sep 2013 18:44:58 +0200 Johnny B frozzensh...@gmail.com wrote: Ben /home doit appartenir UNIQUEMENT et SEULEMENT au user en question voila tout Bzzz, FAIL! C'est /home/user qui

Re: Droits root root dans /home/user perdus

-10 19:07 . drwxr-xr-x 10 ca ca 4096 2013-02-16 13:14 .. Comment rétablir les droits de la deuxième ligne comme ceci ? : drwxr-xr-x 10 root root 4096 2013-02-16 13:14 .. À partir de ces lignes bien connues des admin Linux, il ne peut y avoir d'ambigüité. Curieusement, le contenu de mon mail

[résolu] exécuter des commandes avec droits root (hypothèse sudo)

Bonjour, Sissi(c) ils le sont conformément à ce qui est décrit dans la procédure citée dans mon post initial bon en fait se délogguer n'était pas suffisant. Il fallait rebooter pour que cela fonctionne, du moins face au test d'aptitude Quand je dit aptitude, je ne parle pas juste

Re: [résolu] exécuter des commandes avec droits root (hypothèse sudo)

On Sun, 4 Nov 2012 10:37:29 +0100 Grégory Bulot debian.list200...@batman.dyndns.org wrote: bon en fait se délogguer n'était pas suffisant. Il fallait rebooter pour que cela fonctionne, du moins face au test d'aptitude Un simple '/etc/init.d/sudo restart' devrait être suffisant... -- lea

Re: [résolu] exécuter des commandes avec droits root (hypothèse sudo)

Bonjour, Bonsoir, Le Sun, 4 Nov 2012 11:31:20 +0100, Bzzz, vous avez écrit : Il fallait rebooter pour que cela fonctionne, du moins face au test d'aptitude Un simple '/etc/init.d/sudo restart' devrait être suffisant... J'avais même pas imaginé qu'il existait un service : Merci !

Re: [résolu] exécuter des commandes avec droits root (hypothèse sudo)

On Sun, 4 Nov 2012 12:15:01 +0100 Grégory Bulot debian.list200...@batman.dyndns.org wrote: Par contre je pense que seul un start est pertinent car dans le script : stop|reload|restart|force-reload) ;; Si les commandes des daemons ont été _standardisées_, c'est justement pour éviter

Re: [squeeze] exécuter des commandes avec droits root (hypothèse sudo)

Bonjour, Le vendredi 02 novembre 2012, Grégory Bulot a écrit... MYADMINS ALL=(ALL) NOPASSWD: PKGMGMT, SHUTDOWN PKGMGMT et SHUTDOWN semblent être ce que sudo appelle des Cmnd_Alias, mais ils ne sont pas définis : Cmnd_Alias SHUTDOWN = /sbin/shutdown -- jm -- Lisez la FAQ de la

Re: [squeeze] exécuter des commandes avec droits root (hypothèse sudo)

Bonjour, Bonsoir, Le Sat, 3 Nov 2012 02:27:48 +0100, Raphaël POITEVIN, vous avez écrit : MYADMINS ALL=NOPASSWD: PKGMGMT, SHUTDOWN Je me demande s'il ne faut pas mettre le chemin entier : /sbin/shutdown SHUTDOWN (en majuscule dans la conf, c'est pas pour crier :-D) est un alias. Dans la

Re: [squeeze] exécuter des commandes avec droits root (hypothèse sudo)

Bonjour, Bonsoir, Le Sat, 3 Nov 2012 07:37:10 +0100, Jean-Michel OLTRA, vous avez écrit : Bonjour, Le vendredi 02 novembre 2012, Grégory Bulot a écrit... MYADMINS ALL=(ALL) NOPASSWD: PKGMGMT, SHUTDOWN PKGMGMT et SHUTDOWN semblent être ce que sudo appelle des Cmnd_Alias,

Re: [squeeze] exécuter des commandes avec droits root (hypothèse sudo)

Bonjour, Le samedi 03 novembre 2012, Grégory Bulot a écrit... Sissi(c) ils le sont conformément à ce qui est décrit dans la procédure citée dans mon post initial Désolé, je n'ai pas lu le document. Quels sont les droits du fichier qui est dans sudoers.d/ ? Si il n'est pas en 440, mets

Re: [squeeze] exécuter des commandes avec droits root (hypothèse sudo)

Bonjour, Le Sat, 3 Nov 2012 11:02:40 +0100, Jean-Michel OLTRA, vous avez écrit : Quels sont les droits du fichier qui est dans sudoers.d/ ? Si il n'est pas en 440, mets le en 440 et ré-essaie. J'ai eu le cas dernièrement avec un collègue root sur une de nos machines ayant édité un fichier

Re: [squeeze] exécuter des commandes avec droits root (hypothèse sudo)

Bonjour, Le samedi 03 novembre 2012, Grégory Bulot a écrit... Cmnd_Alias SHUTDOWN = /sbin/shutdown Sissi(c) ils le sont conformément à ce qui est décrit dans la procédure citée dans mon post initial Tu devrais faire passer l'intégralité de tes fichiers, car je viens de créer un

Re: [squeeze] exécuter des commandes avec droits root ( hypothèse sudo)

Le samedi 3 novembre 2012 16:50:26, Jean-Michel OLTRA a écrit : Bonjour, Le samedi 03 novembre 2012, Grégory Bulot a écrit... Cmnd_Alias SHUTDOWN = /sbin/shutdown Sissi(c) ils le sont conformément à ce qui est décrit dans la procédure citée dans mon post initial Tu devrais

Re: [squeeze] exécuter des commandes avec droits root (hypothèse sudo)

Bonjour, Le 02/11/12, Grégory Bulotdebian.list200...@batman.dyndns.org a écrit : j'ai mis ma config dans dans /etc/sudoers.d/gbu plutôt qu'une édition via visudo Test réussis en saisissant le mot de passe de l'utilisateur. Super je me dit que j'ai plus qu'a désactivé le mot de passe, sans

rsync : problème de droits

Bonjour à tous, suite à vos conseils, j'ai mis en place la sauvegarde des données de mon serveur grâce à une commande rsync : rsync -a --del --ignore-errors --force /home/carmelo/ /mnt/NAS-Volume_2/home_debian/carmelo/ NAS-Volume_2 est un montage de mon NAS, montage effectué par fstab via :

Re: rsync : problème de droits

Le Thu, 9 Feb 2012 10:09:39 +0100, Carmelo carm...@ingrao.fr a écrit : NAS-Volume_2 est un montage de mon NAS, montage effectué par fstab via : //192.168.1.100/Volume_2/mnt/NAS-Volume_2 cifs user=Carmelo,password=password,uid=1000,gid=1000,rw 0 0 Le montage est

Re: rsync : problème de droits

Le jeudi 09 février de l'année 2012, vers 10 heures et 09 minutes, Carmelo écrivait: J'en ai déduit que cela vient du montage de mon NAS : les fichiers de michel copiés par rsync appartiennent une fois sur le nas à carmelo ... Avez-vous une idée ? Bonjour, quels sont les droits du fichier

Re: rsync : problème de droits

? Bonjour, quels sont les droits du fichier cible ? le fichier cible, sur le NAS donc, sont : drwxrwxrwx 3 carmelo carmelo 0 9 févr. 05:59 michel donc le répertoire michel, qui à l'origine appartient à michel, se retrouve désormais sous la tutelle de carmelo lors de la copie vers

Re: Droits sur les montages automatiques dans un chroot

Le Mon, 12 Sep 2011 11:40:02 +0200, Guy Roussin a écrit : Du coup dans le chroot, l'utilisateur ne peut pas accéder à la clé usb . Y-a t-il moyen de contourner ce problème je ne sais pas si c'est la solution pour ton cas : violent : un chmod 777 (en root bien sur) du chemin de ta clé quand

Re: Droits sur les montages automatiques dans un chroot

: /media /var/chroot/maverick/media none bind 0 0 Je vois bien un /media dans le chroot avec les mêmes droits que dans la squeeze. Lorsque je branche une clé USB, j'ai dans la squeeze les droits suivants pour la clé : $ ls -al /media/ drwxr-xr-x 4 root root 4096 12 sept. 10:47 . ... drwx-- 19 guy

Re: Droits sur les montages automatiques dans un chroot

Du coup dans le chroot, l'utilisateur ne peut pas accéder à la clé usb . Y-a t-il moyen de contourner ce problème je ne sais pas si c'est la solution pour ton cas : violent : un chmod 777 (en root bien sur) du chemin de ta clé quand elle est montée. J'ai fait cela pour configurer mes accès

Droits sur les montages automatiques dans un chroot

Bonjour, J'ai une debian squeeze (amd64) sur laquelle j'ai installé un chroot maverick pour une utilisation particulière. J'ai ajouté dans /etc/fstab (de la squeeze) la ligne suivante : /media /var/chroot/maverick/media none bind 0 0 Je vois bien un /media dans le chroot avec les mêmes droits

Re: probleme de droits suite à un montage nfs

Ok, j'ai essayé et ça marche !! Merci !! Le mardi 17 mai 2011 à 23:00 +0200, JF Straeten a écrit : Re, On Tue, May 17, 2011 at 10:33:56PM +0200, sailerman wrote: sur une machine squeeze j'ai monté un disque reseau en nfs, j'ai bien accès aux données et je peux créer des fichier (en

probleme de droits suite à un montage nfs

bonsoir, sur une machine squeeze j'ai monté un disque reseau en nfs, j'ai bien accès aux données et je peux créer des fichier (en forçant avec vi par exemple car read-only a priori) mais impossible d'exécuter un programme à partir du répertoire monté. Même pas en root. Je suis obligé de copier

Re: probleme de droits suite à un montage nfs

Re, On Tue, May 17, 2011 at 10:33:56PM +0200, sailerman wrote: sur une machine squeeze j'ai monté un disque reseau en nfs, j'ai bien accès aux données et je peux créer des fichier (en forçant avec vi par exemple car read-only a priori) mais impossible d'exécuter un programme à partir du

Comment limiter les droits d'un utilisateur et de son groupe?

Un optiplex 2950 dell, j'y ai mis une debian Squeeze en 64 bits et j'ai installé un serveur ftp (vsftp pour être plus précis) qui n'est acccessible qu'en interne. J'ai crée un un utilisateur trucmuche et son groupe trucmuche. Je voudrais limiter les droits de cet utilisateur et de son groupe. Dans

Re: Comment limiter les droits d'un utilisateur et de son groupe?

voudrais limiter les droits de cet utilisateur et de son groupe. Dans /etc/ssh/sshd_config j'ai ajouté DenyGroups trucmuche DenyUsers trucmuche Mais que pourrais je faire d'autre pour limiter l'accés à trucmuche et son groupe? Est-ce que tu es obligé de créer un utilisateur Unix trucmuche

Re: Comment limiter les droits d'un utilisateur et de son groupe?

crée un un utilisateur trucmuche et son groupe trucmuche. Je voudrais limiter les droits de cet utilisateur et de son groupe. Dans /etc/ssh/sshd_config j'ai ajouté DenyGroups trucmuche DenyUsers trucmuche Mais que pourrais je faire d'autre pour limiter l'accés à trucmuche et son groupe

  1   2   3   4   5   6   7   >