Effectivement, cela ressemble à un problème d’UID : ce n’est pas le même compte root pour la commande chmod et le propriétaire du dossier records. Un ls -li suivi d’un id devrait le confirmer.
La question c’est comment as-tu créé ce dossier records vs le dossier segments ?
merci pour ta réponse.
Peur de ne pas avoir bien compris la commande:
root@Ubuntu-Jeedom:/var/www/html/plugins/camera/data# ls -li 33
ls: impossible d’accéder à ‹ 33 ›: Aucun fichier ou dossier de ce type
les répertoires ont déja été créés par le systeme Jeedom et pour éviter de saturer l’espace de la VM je voulais déporter sur Pcloud et je ne peux pas modifier le répertoire /var/www/html/plugins/camera/data car codage en dur dans jeedom.
Bon, c’est pas très clair, ça se complique pas mal, et ça me dépasse un peu j’en ai peur.
En plus je me suis trompé : c’est l’option « -n » de la commande ls (disons ls -ln typiquement) va te permettre d’afficher les UID/GID (au lieu de user et group) pour chaque fichier/dossier. Cela devrait te permettre de voir si le compte root (dont tu auras le UID en tapant simplement la commande id au prompt) est bien le même que le propriétaire du dossier records.
Deux commandes séparées donc : « ls -ln » pour voir les UID à qui appartiennent les fichiers, et « id » pour connaître l’UID du compte root utilisé dans ton shell. C’était ça l’idée, pour essayer de comprendre pourquoi ta commande chown ne marche pas.
-=-
Pour résumer de ce que je comprends :
Donc tu as un compte PCloud. Tu montes ce drive en davfs sur la machine pve sur /mnt/pcloudjc.
Puis tu partages ce dossier via Samba Server ? Pourquoi je vois le partage sur /mnt/pve ? je m’attendrais à voir /mnt/pcloudjc.
Ensuite, dans une VM appelée Ubuntu-Jeedom (sur une autre machine physique ?), tu as une appli Jeedom (de la domotique, je ne connais pas) qui a ses propres fichiers et son arborescence. Et tu veux utiliser le partage Samba pour que Jeedom écrive ses fichiers dans le PCloud, mais uniquement le dossier records. Les autres dossier comme segments restant en local.
Comment et sur quoi est fait le mount dont tu parles dans ton deuxième post : mount /var/www/html/plugins/camera/data/records ?? Manifestement les droits d’écriture y sont restreints, et www-data n’a pas les droits d’écriture. En changeant les droits d’écriture, tu n’aurais plus besoin de modifier le propriétaire.
C’est important de bien décrire la situation, parce franchement avec ton premier post, pour s’y retrouver, c’est impossible ! Et même au deuxième… Fais aussi attention à utiliser le tag « code » (texte préformatté) pour tes copies de commande, et à les vérifier dans le panneau"preview" pour que tout cela soit lisible pour les autres.
Essaie de mettre déjà tout ton schéma sur papier, qui monte quoi et avec quelles permissions. Ça devrait t’aider à y voir plus clair. À chaque couche, il faut avoir les droits.
Pourquoi passer par le share samba d’une autre machine ? pourquoi ne pas monter directement dans ta VM ton drive PCloud et y faire pointer Jeedom pour ses fichiers ?
À priori bonne idée, encore faut-il que Jeedom le supporte, à tester. La commande pour un lien symbolique, c’est ln -s, je ne la vois pas dans ta première commande : faute de frappe ?
Sinon le ls -n que tu fais ensuite n’a aucune incidence, ce n’est que de l’affichage.
On voit voit un lien symbolique Camera qui pointe sur /mnt/pcloud/Jeedom/Camera/, et qui se trouve si je ne me trompe pas dans /var/www/html/plugins/camera/data/records.
Pour le supprimer, c’est un fichier comme un autre : rm /var/www/html/plugins/camera/data/records/Camera
Et tu refais le lien que tu souhaites ensuite: ln -s CIBLE NOM_LIEN en te plaçant dans le dossier où tu souhaites créer ce lien.
Et même au deuxième… Fais aussi attention à utiliser le tag « code » (texte préformatté) pour tes copies de commande, et à les vérifier dans le panneau"preview" pour que tout cela soit lisible pour les autres.