Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 21/11/2020, à 21:25

Durahsel

"Permission non accordée" à l'ouverture d'un fichier propriétaire

Bonjour

Suite à un changement de PC mais reprenant le même compte utilisateur avec ses accès vers un disque dur externe, je n'ai dans l'ensemble aucun problème sur les accès en lecure / écriture de ce dernier.
Par contre sur certains fichiers, je ne peux même plus les ouvrir. J'ai également fait des essais sur windows : plus d'accès au fichier.
Voici un exemple

sur les droits de ce répertoire :

famille@famille-MS-7C37:/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage$ ls -l
total 712
-rwxr-xr-x 1 famille root 634008 juin   8 21:28 'Broyeur WC sanitaire avec Alarme BSF-600D .pdf'
-rwxr-xr-x 1 famille root  93675 juin   8 21:28 'Capture du 2020-06-08 21-27-40.png'
drwxr-xr-x 2 famille root      0 nov.  21 21:07  electrolyse
famille@famille-MS-7C37:/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage$ 

je ne peux pas ouvrir ou me copier avec sudo le fichier suivant, exemple :

famille@famille-MS-7C37:/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage$ sudo cp '/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage/Broyeur WC sanitaire avec Alarme BSF-600D .pdf' '/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage/test.pdf'
cp: impossible d'ouvrir '/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage/Broyeur WC sanitaire avec Alarme BSF-600D .pdf' en lecture: Permission non accordée

sur le fichier voisin ça marche, pas d'erreur alors que les droits sont les même ...

famille@famille-MS-7C37:/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage$ sudo cp '/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage/Capture du 2020-06-08 21-27-40.png'  '/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage/test.png' 
famille@famille-MS-7C37:/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage$ 

et ce problème se présente sur plusieurs fichiers (je le vois lorsque j'essaye de faire des sauvegarde backintime).

Quelqu'un aurait-il une idée sur l'origine du problème ? (je ne vois par exemple pas pourquoi qlq fichiers seraient subitement devenus corrompus ... ?)

merci d'avance !


---
Ubuntu 20.04.1

Hors ligne

#2 Le 21/11/2020, à 22:41

kamaris

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Tu as essayé de faire un chkdsk /f sur la partition concernée sous windows ?

Hors ligne

#3 Le 21/11/2020, à 23:28

Durahsel

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

s'agissant d'un disque réseau, windows ne peut pas le faire, je l'ai fait avec l'utilitaire du disque et RAS


---
Ubuntu 20.04.1

Hors ligne

#4 Le 22/11/2020, à 09:59

bruno

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

+1
C'est presque à coup sûr un problème de disque ou de système de fichiers corrompu.
Il faudrait savoir quel système de fichiers est utilisé et éventuellement faire une vérification du disque avec les smartmontools.

Hors ligne

#5 Le 23/11/2020, à 21:07

Durahsel

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

comme le disque est en réseau, pas possible de l'analyser avec smartmontools. J'ai par contre fait des analyses avec l'utilitaire sur l'interface réseau (micrologiciel du disque), analyse matérielle et approfondie système et tout est ok


---
Ubuntu 20.04.1

Hors ligne

#6 Le 24/11/2020, à 13:26

moko138

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Peux-tu montrer (disque branché, voire monté) :

sudo lsblk -o name,fstype,size,label,mountpoint -e7,11 ; echo -e "\n\t\t\t= = =\nDésignations...\n\t...stables\t\t\t                     ...instables :"; ls -l /dev/disk/by-id | grep -Evi "\-part[3-9]|Reader|\-part[1-9][0-9]|sr[0-9]" | awk '{print $9,$11}' | sort -k2 | column -s' ' -t

%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#7 Le 24/11/2020, à 14:46

bruno

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Effectivement savoir comment le disque est monté pour peut-être aider. Dan ce cas, le retour de :

mount | grep media

suffit.

D'après le nom du point de montage il s’agirait d'un WD MyCloud . C'est un système on ne peut plus fermé (pour ne pas dire privateur) et on ne peut pas faire grand chose à part sortir le disque et le brancher directement sur un ordinateur pour tenter de réparer le système de fichiers.

Hors ligne

#8 Le 30/11/2020, à 20:44

Durahsel

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Bonjour
voici le résultat pour la première commande

NAME        FSTYPE   SIZE LABEL     MOUNTPOINT
sda                  1,8T           
└─sda1      ntfs     980G Stock1To  /media/Stock1To
sdb                465,8G           
└─sdb1      ext4   465,8G RescueMDR /media/famille/RescueMDR
nvme0n1            931,5G           
├─nvme0n1p1 vfat     100M           /boot/efi
├─nvme0n1p2           16M           
├─nvme0n1p3 ntfs   463,3G           
├─nvme0n1p4 ntfs     519M           
└─nvme0n1p5 ext4   467,7G           /

et la deuxième :

$ mount | grep media
/dev/sda1 on /media/Stock1To type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
//192.168.1.32/Public on /media/MyCloudWD type cifs (rw,relatime,vers=3.1.1,cache=strict,username=admin,uid=1000,forceuid,gid=0,noforcegid,addr=192.168.1.32,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1)
/dev/sdb1 on /media/famille/RescueMDR type ext4 (rw,nosuid,nodev,relatime,uhelper=udisks2)

---
Ubuntu 20.04.1

Hors ligne

#9 Le 30/11/2020, à 22:27

moko138

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Le 24/11, moko138 a écrit :

Peux-tu montrer (disque branché, voire monté) :

sudo lsblk -o name,fstype,size,label,mountpoint -e7,11 ; echo -e "\n\t\t\t= = =\nDésignations...\n\t...stables\t\t\t                     ...instables :"; ls -l /dev/disk/by-id | grep -Evi "\-part[3-9]|Reader|\-part[1-9][0-9]|sr[0-9]" | awk '{print $9,$11}' | sort -k2 | column -s' ' -t

Bis, et, cette fois, sans couper la deuxième moitié du retour.
Merci !


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#10 Le 30/11/2020, à 22:53

Durahsel

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

moko138 a écrit :

Bis, et, cette fois, sans couper la deuxième moitié du retour.

oups désolé:

NAME        FSTYPE   SIZE LABEL     MOUNTPOINT
sda                  1,8T           
└─sda1      ntfs     980G Stock1To  /media/Stock1To
sdb                465,8G           
└─sdb1      ext4   465,8G RescueMDR /media/famille/RescueMDR
nvme0n1            931,5G           
├─nvme0n1p1 vfat     100M           /boot/efi
├─nvme0n1p2           16M           
├─nvme0n1p3 ntfs   463,3G           
├─nvme0n1p4 ntfs     519M           
└─nvme0n1p5 ext4   467,7G           /

			= = =
Désignations...
	...stables			                     ...instables :
nvme-eui.0025385501406f6b                           ../../nvme0n1
nvme-Samsung_SSD_970_EVO_1TB_S5H9NS0N516061T        ../../nvme0n1
nvme-eui.0025385501406f6b-part1                     ../../nvme0n1p1
nvme-Samsung_SSD_970_EVO_1TB_S5H9NS0N516061T-part1  ../../nvme0n1p1
nvme-eui.0025385501406f6b-part2                     ../../nvme0n1p2
nvme-Samsung_SSD_970_EVO_1TB_S5H9NS0N516061T-part2  ../../nvme0n1p2
ata-ST2000DM008-2FR102_WFL3AHKH                     ../../sda
wwn-0x5000c500ccb43e29                              ../../sda
ata-ST2000DM008-2FR102_WFL3AHKH-part1               ../../sda1
wwn-0x5000c500ccb43e29-part1                        ../../sda1
ata-WDC_WD5000BMVV-11GNWS0_WD-WXM1A80N1182          ../../sdb
wwn-0x50014ee655c961de                              ../../sdb
ata-WDC_WD5000BMVV-11GNWS0_WD-WXM1A80N1182-part1    ../../sdb1
wwn-0x50014ee655c961de-part1                        ../../sdb1

---
Ubuntu 20.04.1

Hors ligne

#11 Le 01/12/2020, à 01:39

moko138

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Problème :

//192.168.1.32/Public on /media/MyCloudWD

n'apparaît pas dans ce retour, pas même sous forme non montée.
  Était-il seulement branché ?

(On a bien un Western Digital, mais c'est celui contenant

└─sdb1      ext4   465,8G RescueMDR /media/famille/RescueMDR

et on a vu, par le retour de mount au #8, qu'ils étaient deux disques différents.)


Débrouille-toi comme tu veux, mais il faut
  - rendre le disque visible (même sans monter son système de fichiers)
  - lire ses données smart avant de contrôler son FS, pour s'assurer qu'il est en état de supporter cette vérification sans perte supplémentaire de données.
  Si besoin, tu peux, le temps de cette vérification, le brancher autrement qu'en réseau.


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#12 Le 01/12/2020, à 03:07

Coeur Noir

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

//192.168.1.32/Public on /media/MyCloudWD type cifs (rw,relatime,vers=3.1.1,cache=strict,username=admin,uid=1000,forceuid,gid=0,noforcegid,addr=192.168.1.32,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1)

Elle sort d'où cette ligne de montage ? Curiosité, car elle a beaucoup d'options. Certaines (m')évoquent samba.

-rwxr-xr-x 1 famille root 634008 juin   8 21:28 'Broyeur WC sanitaire avec Alarme BSF-600D .pdf'

⋅ attention au caractère espace dans les noms de fichiers. Puisque le chemin est entre guillemets simples dans l'exemple cp, ça n'est probablement pas le problème. C'est quand même un risque de confusion dans certaines circonstances.
pdf. Est-ce qu'un pdf protégé par mot de passe peut empêcher qu'on le copie ( tant qu'on n'a pas « passé » le mot de passe quelque part ) ? Je n'en sais rien, juste une idée en l'air. Est-ce que mv ( déplacer / renommer ) plutôt que cp ( copier ) fonctionnerait ?
cp: impossible d'ouvrir ouvrir… alors qu'il veut juste copier ? Ça me sonne bizarre aux yeux. Un rapport avec file_mode=0755 qui laisse le droit d'exécution sur les fichiers ? Il vaudrait mieux 0644 à cet endroit ( soit rw-r--r-- ).
samba n'est peut-être pas le sujet ici, mais c'est assez facile d'avoir sous samba via ses config's de partages et utilisateurs, des « droits et permissions » plus contraignants voire en contradiction avec ceux côté Linux. Pas toujours évident d'harmoniser les 2 univers…

Dernière modification par Coeur Noir (Le 01/12/2020, à 14:33)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#13 Le 01/12/2020, à 09:58

bruno

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

En #11 il n'y a pas de problème. C'est juste que la commande inutilement alambiquée que tu as proposée ne permet pas de voir les montages distants (cifs, nfs, etc.). C'est pourquoi j'ai demandé un retour de mount

En #12 effectivement le montage cifs contient beaucoup (trop) d'options. Cela explique les droits d'accès bizarres, bit d’exécution sur de simple fichiers pdf ou png  et groupe root, mais pas les erreurs constatées. J'aimerai aussi bien savoir quelle application a pu générer un tel montage.

Je me suis également posé la question d'un problème avec les caractères (types ou longueur) utilisés pour nommer les fichiers mais je ne vois pas dans l'exemple donné ce qui pourrait différencier le fichier dont la copie fonctionne et celui auquel l'accès est refusé.

Pour s'assurer qu'il ne s'agit pas d'un problème de montage je suggère de faire un montage temporaire dans /mnt :

sudo mount -t cifs -o username=admin,rw,uid=1000,gid=1000,vers=1.0 //192.168.1.32/Public /mnt

Ce qui demandera de sasir le mot de passe de l'utilisateur admin du NAS WDMyCloud.
Puis de naviguer dans l'arborescence de /mnt pour tenter à nouveau de copier un des fichiers problématiques.

Pour annuler ce montage temporaire après les tests :

sudo umount /mnt

Hors ligne

#14 Le 01/12/2020, à 14:36

Coeur Noir

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

bruno, on ne sait jamais : /mnt peut déjà être occupé par un montage, vaut mieux d'abord vérifier, et si vide y créer un sous-dossier, puis utiliser ce sous dossier pour le montage.

ls /mnt

si vide

sudo mkdir /mnt/test

puis

sudo mount -t cifs -o username=admin,rw,uid=1000,gid=1000,file_mode=0644,dir_mode=0755,vers=1.0 //192.168.1.32/Public /mnt/test

pour démonter

sudo umount /mnt/test

je ne vois pas dans l'exemple donné ce qui pourrait différencier le fichier dont la copie fonctionne et celui auquel l'accès est refusé.
Un caractère espace en fin de nom et avant .pdf ( mais bon il est correctement échappé à priori par les guillemets simple ' ' autour du chemin ).

Les options sur le montage : le CloudWD utilise-t-il le protocole samba, ça en expliquerait quelques unes ?


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#15 Le 01/12/2020, à 14:55

bruno

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Mouais… Normalement /mnt est réservé aux montages temporaires, donc oui pour la vérification, non pour la création d'un sous dossier.
C'est évidement un montage SMB puisque le type de montage est cifs mais cela ne permet pas de connaître le système de fichiers sous-jacent.

Hors ligne

#16 Le 01/12/2020, à 16:29

moko138

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

bruno a écrit :

En #11 il n'y a pas de problème. C'est juste que la commande inutilement alambiquée que tu as proposée ne permet pas de voir les montages distants (cifs, nfs, etc.). C'est pourquoi j'ai demandé un retour de mount

OK. Merci de l'info !

Alors, Durahsel, s'il te plaît, montre, sans "/Public", le retour complet de

sudo smartctl -s on -S on -a //192.168.1.32

y compris les éventuels messages d'erreur.
Merci !


%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel :  À la découverte de dcraw

Hors ligne

#17 Le 01/12/2020, à 16:37

bruno

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

moko138 a écrit :
sudo smartctl -s on -S on -a //192.168.1.32

Hein ?!

Hors ligne

#18 Le 01/12/2020, à 20:13

Coeur Noir

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Normalement /mnt est réservé aux montages temporaires,
Ça, va le dire aux concepteurs de gnome-disk-utility qui utilitise par défaut /mnt pour tout, en y créant un sous-dossier par montage.

non pour la création d'un sous dossier.
Et pour quelle curieuse raison ? C'est une bonne pratique, notamment si tu as besoin de + que 1 montage temporaire à la fois…

Historiquement /mnt était le dossier pour tous les montages, il n'a jamais été interdit d'y créer des sous dossiers.
Comme ça y devenait vite le foutoir, on s'est dit qu'un dossier /media permettrait de faire du tri ( avec /media comme destination des périphériques de lecture de data, et /mnt pour le « manuel » ou « temporaire » ).
Puis les habitudes et les appareils évoluant, c'est de nouveau devenu le foutoir, alors Gnome a décidé qu'il fallait automatiquement classer dans ce répertoire /media les diverses ressources dans un sous-dossier par $USER ( d'où udisks× ).

Dernière modification par Coeur Noir (Le 01/12/2020, à 22:43)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#19 Le 01/12/2020, à 21:55

Durahsel

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

vous êtes bien sympathiques de vous pencher sur ce cas qui a l'air tordu mais pas désespéré, du moins j'espère

moko318 a écrit :

Problème :

//192.168.1.32/Public on /media/MyCloudWD
n'apparaît pas dans ce retour, pas même sous forme non montée.
  Était-il seulement branché ?

oui il est branché en RJ45 sur ma box

moko318 a écrit :

  Si besoin, tu peux, le temps de cette vérification, le brancher autrement qu'en réseau.

ben il va falloir que je regarde en effet pour faire un essai de branchement en direct sur le PC, par usb mais je n'ai pas essayé, j'essaierai quand j'aurai un moment

coeur noir a écrit :

Elle sort d'où cette ligne de montage ? Curiosité, car elle a beaucoup d'options. Certaines (m')évoquent samba.

je ne me souviens plus pourquoi et comment mais en efft j'avais utilisé ce point de montage dans fstab (de mémoire j'avais essayé bcp de trucs avant de l'avoir enfin de monté correctement et à chaque démarrage):

//192.168.1.32/Public /media/MyCloudWD cifs uid=famille,credentials=/home/famille/.smbcredentials,iocharset=utf8 0 0
moko318 a écrit :

OK. Merci de l'info !

Alors, Durahsel, s'il te plaît, montre, sans "/Public", le retour complet de

sudo smartctl -s on -S on -a //192.168.1.32

voici :

smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-53-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

//192.168.1.32: Unable to detect device type
Please specify device type with the -d option.

Use smartctl -h to get a usage summary

bon comme ce montage semble poser plus de soucis qu'autre chose, je vais comment le brancher temporairement autrement et ferai un retour


---
Ubuntu 20.04.1

Hors ligne

#20 Le 01/12/2020, à 22:30

Coeur Noir

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Stop.

Le brancher ailleurs / autrement signifiera quand même qu'il faut le monter avec des options adéquates.

Là, même si les options semblent nombreuses et pas forcément toutes pertinentes, tu as un montage qui fonctionne.

Ton problème concerne la copie d'un fichier. Pas l'accès au disque entier.

As-tu d'abord vérifié / in⋅validé les hypothèses du #12 concernant ce fichier :
⋅ espace mal placée dans son nom,
⋅ pdf protégé par mot de passe,
⋅ test avec mv au lieu de cp
⋅ fichier avec droit d'exécution, non requis sur un pdf ( requis sur un script ou un binaire, mais pas sur ce genre de fichiers « data » associés à une application graphique ).

Ensuite messages #13, #14 : je pense très fort que le file_mode=0755 est problématique.

Dernière modification par Coeur Noir (Le 01/12/2020, à 22:37)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#21 Le 01/12/2020, à 23:04

Durahsel

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

c'est noté

déjà sur ces points :

coeur noir a écrit :

As-tu d'abord vérifié / in⋅validé les hypothèses du #12 concernant ce fichier :
⋅ espace mal placée dans son nom,
⋅ pdf protégé par mot de passe,
⋅ test avec mv au lieu de cp
⋅ fichier avec droit d'exécution, non requis sur un pdf ( requis sur un script ou un binaire, mais pas sur ce genre de fichiers « data » associés à une application graphique ).

je suivrai les préco #13 et #14 et ferai un retour
espace et mv : j'ai renommé le fichier sans espace, et la commande suivante fonctionne :

sudo mv '/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/bricolage/BroyeurBSF-600D.pdf' '/media/MyCloudWD/0 Pierre Doc BIS/autres fantaisies/'  

avec cp ça ne marche pas

le pdf n'est pas protégé par un mot de passe
(j'ai le soucis sur 2/3 autres fichiers non protégés mais en effet, il semble que le problème ne se produise que sur des pdf)


---
Ubuntu 20.04.1

Hors ligne

#22 Le 01/12/2020, à 23:31

beuguissime

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Bonsoir,

En passant…
Si le système de fichier est dans un état incertain, je ne suis pas sûr que le test avec mv effectué soit parlant : c'est un déplacement sur le même support donc pas vraiment une lecture du fichier et des secteurs sous-jacents, et donc des erreurs sur les secteurs ne gêneraient pas forcément une opération mv, au contraire d'une opération cp.

Coeur Noir,
moko, bruno, kamaris voudraient un accès direct au disque (donc via /dev/sdX) pour pouvoir faire la maintenance qui semble impossible via l'interface logicielle propriétaire du disque et impossible via un montage réseau.

Bon courage pour la suite.

Hors ligne

#23 Le 02/12/2020, à 00:57

Coeur Noir

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

@beuguissime, et les autres.

J'ai bien compris que vous souhaitez un accès direct à ce disque pour en vérifier l'état du système de fichiers. Et c'est toujours très bien d'effectuer une telle vérification.

Mon hypothèse ici c'est qu'on est ( encore, comme souvent, par pure intuition empirique ) face à un problème logiciel, plus précisément un problème concernant les droits et permissions.
Rappel : on a vu cifs → suggère samba → suggère ntfs ou fat ou autre système de fichiers non linux à l'autre bout, sans gestion des droits et permissions.

La commande cp tente d'ouvrir ce fichier. La commande mv passe sans accroc. Je pense que si ce fichier n'avait plus le droit d'exécution, la commande cp passerait sans problème.

Maintenant, si ce montage

//192.168.1.32/Public on /media/MyCloudWD type cifs (rw,relatime,vers=3.1.1,cache=strict,username=admin,uid=1000,forceuid,gid=0,noforcegid,addr=192.168.1.32,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1)

pouvait devenir

//192.168.1.32/Public on /media/MyCloudWD type cifs (rw,relatime,vers=3.1.1,cache=strict,username=admin,uid=1000,forceuid,gid=0,noforcegid,addr=192.168.1.32,file_mode=0644,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1)

j'aimerais bien voir si ça résout le problème de copie.

Sur quoi fondè-je cette hypothèse : sans option particulière, le montage d'un système de fichiers non Linux donne souvent tout à root, avec droits rwxrwxrwx.
Ici on a bien des options qui émulent, sur tout le montage côté Linux, des droits qui n'existent pas sur le système de fichiers distant :
⋅ pour approprier ( uid=1000,forceuid,gid=0,noforcegid ) à famille:root et imposer famille comme utilisateur propriétaire à tout fichier créé par là,
⋅ pour accorder les droits rwxr-xr-x aux fichiers et dossiers ( file_mode et dir_mode tous deux à 0755 ) alors que pour les fichiers la base c'est rw-r--r-- ( soit file_mode=0644 )
vers=3.1.1 suggère un niveau de protocole samba
⋅ les autres options ( hors rw ) je ne les connais pas : relatime, soft, nounix, serverino, mapposix, rsize, wsize, bsize, echo_interval, actimeo

Cela n'exclut évidemment pas que le système de fichiers distant puisse avoir des pets au casque. Mais puisqu'il y a de fortes chances qu'il s'agisse d'un truc non Linux, vous le réparerez comment ?
Y-a-t-il une interface à ce machin cloudWD ? Ou c'est juste un disque dur externe branché au réseau via une box-routeur ? Y-a-t-il un Windows dans les parages qui serait en mesure de réparer du NTFS ou du FAT ?

Dernière modification par Coeur Noir (Le 02/12/2020, à 01:01)


DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne

#24 Le 02/12/2020, à 01:04

beuguissime

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

Au n°1, les deux fichiers tests ont les mêmes permissions apparentes mais deux comportements différents vis-à-vis de cp. Donc je pense que je loupe une étape de ton raisonnement.

Hors ligne

#25 Le 02/12/2020, à 01:48

Coeur Noir

Re : "Permission non accordée" à l'ouverture d'un fichier propriétaire

L'un est un .png l'autre un .pdf ( un .pdf est une forme d'archive - pas sûr du comportement si on tente son exécution ).

S'il y a d'autres fichiers non copiables via cp, qu'ont-ils de commun ? Tous des .pdf ? Tous une forme d'archive ( .zip, .odt, .xlsx ) ?

Et ça ne coûte rien de rectifier puisque de toute façon file_mode=0644 fournira une situation plus saine que file_mode=0755.

Au fait pourquoi sudo cp à la base ? Les fichiers appartiennent à l'utilisateur famille, et sont manipulés depuis un terminal en famille@famille ? Que dit

ls -la /media

DébuterDocBien rédigerRetour commandeInsérer image | illustrations & captures d'écran <>

Hors ligne