Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Dualboot Win10-linux-data NTFS partagé-write inhibé après màj

ujmo

Bonjour,
Jusqu'à ce que je fasse le dernier upgrade de Windows 10 j'avais mon disque de données partagé entre linux et windows et je disposais de l'accès contrôle total de part et d'autre.
J'ai installé le dernier upgrade de windows 10 dont la date limite était le 10 avril.
Après cela : impossible de créer des dossiers, des fichiers, etc sur mon disque data depuis linux (l'accès en écriture est inhibé)
Je me passerais bien de windows s'il n'y avait pas ces logiciels propriétaires (imposés par mon club) qui ne tournent que sous Windows et même pas sous Wine.
J'ai bien vérifié que le montage des partitions est effectué sous linux.
J'accède donc en lecture et exécution mais non en écriture.
Quelqu'un d'entre vous aurait-il eu et résolu ce problème ?
Je lui serais alors extrêmement reconnaissant de m'aider pour me sortir de cette embûche.
Je voudrais éviter de reformater après sauvegarde en ext4 puis restauration et permettre à windows d'accéder aux données par ext2.
Merci et bonne journée.
ujmo

système 64b : kde 17.10 plasma 5.12.4 - noyau linux 4.16.0 -

jamesbad000

Bonjour.

Dans un premier temps donner le retour de

sudo lsblk -o size,name,fstype,label,mountpoint
sudo mount -l

ujmo

Merci James
En retour :
Listage des partitions :

  SIZE NAME   FSTYPE LABEL    MOUNTPOINT
698,7G sda                    
   25G ├─sda1 vfat   RECOVERY 
171,3G ├─sda2 ntfs   OS       /media/ujmo4612/OS
  484M ├─sda3 swap            [SWAP]
    1K ├─sda4                 
394,2G ├─sda5 ntfs   DATA     /DATA
 33,5G ├─sda6 ext4            /
 74,1G └─sda7 ext4            /home
931,5G sdb                    
419,1G ├─sdb1 ext4   sav      /media/ujmo4612/sav
512,4G ├─sdb2 ntfs   datas    /media/ujmo4612/datas
    2M └─sdb3 ext4   isoVM    /media/ujmo4612/isoVM
 1024M sr0

___________________________________________
Listing des montages

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1945848k,nr_inodes=486462,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=394748k,mode=755)
/dev/sda6 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=19478)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime)
/dev/sdb2 on /media/ujmo4612/datas type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) [datas]
/dev/sdb1 on /media/ujmo4612/sav type ext4 (rw,relatime,data=ordered) [sav]
/dev/sda7 on /home type ext4 (rw,relatime,data=ordered)
/dev/sda5 on /DATA type fuseblk (ro,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) [DATA]
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
-hosts on /net type autofs (rw,relatime,fd=6,pgrp=1450,timeout=30,minproto=5,maxproto=5,indirect,pipe_ino=27280)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=394744k,mode=700,uid=1000,gid=1000)
/dev/sdb3 on /media/ujmo4612/isoVM type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2) [isoVM]
/dev/sda2 on /media/ujmo4612/OS type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) [OS]
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

J'ai isolé ici les deux lignes concernées :

394,2G ├─sda5 ntfs   DATA     /DATA

/dev/sda5 on /DATA type fuseblk (ro,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096) [DATA]

effectivement, je vois que la deuxième ligne précise que le montage est fait en read only (ro)
Ne connaissant pas bien les commandes système, j'ai encore appris quelque chose grace à ta réponse.
Ce que je ne m'explique pas c'est pourquoi dès application de l'upgrade de windows 10 cela a brusquement changé car auparavant j'avais les droits en rw.
Je pense que je vais devoir changer les paramètres de montage
mais dans /etc/fstab :

# /DATA was on /dev/sda5 during installation
UUID=4490694790694092 /DATA           ntfs    defaults,umask=007,gid=46 0       0

or la valeur defaults correspond d'après la doc à

(rw,suid,dev,exec,auto,nouser,async)

alors pourquoi "ro" et non "rw" ?
y aurait-il désormais un verrou posé par Windows 10 ?

je te remercie de m'avoir répondu si vite
Bonne journée
ujmo

malbo

Bonjour,
Lors de cette maj de W10, ce dernier a dû réactiver la fonctionnalité démarrage rapide de Windows. Pour vérifier si c'est bien le problème, je te propose de procéder comme suit :
1) démarrer une session W10
2) quitter W10 par "Redémarrer" et non pas par "Arrêter". En effet, quand on quitte W10 par "Redémarrer", la fonctionnalité "démarrage rapide" n'est pas utilisée et les partitions NTFS ne sont pas mises en état "hibernation".
3) dès le redémarrage, sélectionner Ubuntu pour démarrer dessus. Arrivé dans la session Ubuntu, repasse la commande "sudo mount -l " et tu pourras constater que tu as "rw" et pas "ro".

Pour complément d'info, tu peux lire (mais c'est facultatif) ce post dans lequel j'ai étudié la chose : https://forum.ubuntu-fr.org/viewtopic.php?pid=21708052#p21708052

ujmo

Bonjour,
Le problème vient effectivement de Windows 10 et de l'hibernate mais il était bien plus complexe. 😐
Tout d'abord effectivement, Il fallait supprimer l'hibernation sous Windows.
Méthode : exécuter "cmd" en mode administrateur (pour cela rechercher cmd et clic droit pour disposer du menu contextuel et activer le sous menu "exécuter en mode administrateur"
Entrer la commande :

powercfg /h off

Après cela il faut arrêter ou redémarrer, peu importe, car l'hibernation qui bloque les disques pour pouvoir ressortir de veille dans une situation antérieure stable, est désactivée dans tous les cas.

Mais un autre problème subsistait sous windows : le phénomène d'arrêt ou de redémarrage en boucle infinie (j'ai laissé le "redémarrage en cours" sur écran bleu pendant toute une nuit.)
La seule solution pour en sortir : appui continu de 15 secondes sur le bouton power de l'ordinateur.
Mais le problème dans ce cas : la désactivation de l'hibernate n'est pas prise en compte.
La solution a été de redémarrer Windows en mode sans échec :
Ouvrir une session windows (en dual boot on ne peut pas le faire par maj+F8)
Exécuter msconfig en mode administrateur (touche Windows + R) et taper msconfig et suivre les menus qui s'affichent pour redémarrer en mode sans échec.
dans la session windows en mode sans échec :
saisir à nouveau dans le mode sans échec la commande de désactivation de l'hibernate (comme plus haut)
arrêter la session windows (arrêt) et redémarrer sur la session ubuntu.
tout redevient normal.
Sacré Windows !
Merci Malbo c'est ton post qui a vraiment éclairé ma lanterne qui s'était éteinte.
Merci donc à vous deux et bonne continuation sous linux.
à bientôt peut être
ujmo

ujmo

Quelques précisions supplémentaires.
Il ne s'agit pas de déterrer un problème que j'ai signalé résolu mais d'aider tous ceux qui auraient rencontré le même problème.

Le problème était double :
1. Verrouillage des partitions NTFS partagées par le processus d'hibernation de Windows
2. Blocage de l'Arrêt (ou du redémarrage) de Windows dans une boucle infinie et qui empêche la prise en compte de la désactivation de l'hibernation.

pour le point 1 : désactivation de l'hibernation comme indiqué dans le dernier post mais dans une session normale Windows 10

pour le point 2 : trouver le processus qui empêche la clôture de windows
Dans le cas qui a provoqué le blocage que je signale, il s'agissait de Ext2Fsd qui permet d'accéder en écriture su les partitions linux Ext4 mais qui ne fonctionne plus avec Windows 10
A ma connaissance il n'existe pas de logiciel qui permette actuellement la compatibilité avec Windows 10.
Il faut effectuer la désinstallation totale de Ext2Fsd

On peut cependant utiliser sous windows Ext2Read qui permet au moins d'accéder en lecture sur les partitions linux.
Dans le cas où on ne peut pas déterminer le processus qui bloque l'arrêt de Windows 10 il y a la possibilité de préciser l'option remove hiberfil.sys au montage des partitions partagées.
Mais ce n'est pas une solution propre et elle impose de vérifier auparavant que le fichier n'existe pas à la racine de la partition système de windows.
J'espère que ces quelques considérations pourront aider ceux qui auront rencontré un problème similaire

Bon linux à tous.

malbo

ujmo a écrit il s'agissait de Ext2Fsd qui permet d'accéder en écriture su les partitions linux Ext4 mais qui ne fonctionne plus avec Windows 10

Je n'ai jamais pratiqué ce logiciel Ext2Fsd mais je constate que la doc Comment accéder à ses partitions d'Ubuntu sous Windows ? confirme cela puisqu'on peut y lire la note suivante dans le paragraphe 1. Ext2fsd :

Ce logiciel n'est pas compatible avec Windows 10, qui ne pourra plus mettre en route si EXT2FSD est installé

Ce qui me parait curieux, c'est que ce logiciel Ext2Fsd semble toujours maintenu puisque sa dernière version 0.69 est datée du 2 novembre 2017 (voir cette page). Maintenir cette daube alors qu'elle n'est pas compatible Windows 10, c'est bizarre...

ujmo

Le problème c'est que même dans le cas où on répondait non à la mise en route du processus, le phénomène subsistait.
La seule solution est donc la désinstallation.