J'utilise Ubuntu 16.04.4 LTS et rencontre un problème. Tout à coup, je suis incapable de modifier des fichiers comme je le pouvais auparavant, je ne peux pas exécuter de programmes en raison d'erreurs d'autorisation.
Je suis toujours connecté en tant qu'utilisateur ejaz
appartenant au groupe primaire ejaz
et aux groupes secondaires root
adm
cdrom
Sudo
dip
www-data
plugdev
lpadmin
sambashare
kismet
wireshark
docker
. J'ai plusieurs sites Web dans des sous-répertoires de /var/www/html/
(pas dans ~/public_html
parce que c'est une machine de développement sans considérations de sécurité/partage). Prenant un site Web, /var/www/html/test
, par exemple; il appartient à l'utilisateur: groupe www-data:www-data
. Moi, connecté en tant que ejaz
, je reçois des erreurs d'autorisation lors de la modification de fichiers dans le répertoire test
. Je semble avoir les autorisations de groupe correctes pour éditer ce répertoire.
groups
~ » groups ejaz
ejaz : ejaz root adm cdrom Sudo dip www-data plugdev lpadmin sambashare kismet wireshark docker
test
site/var/www/html » l | grep test
drwxrwxr-x 2 www-data www-data 4.0K Apr 9 2017 test
/var/www/html » cd test
/var/www/html/test » l
total 16K
drwxrwxr-x 2 www-data www-data 4.0K Apr 9 2017 .
drwxrwxr-x 87 www-data www-data 4.0K Jul 10 06:50 ..
-rw-rw-r-- 1 www-data www-data 0 Apr 9 2017 blah.html
-rw-rw-r-- 1 www-data www-data 16 Apr 9 2017 .htaccess
-rw-rw-r-- 1 www-data www-data 73 Apr 9 2017 index1.html
/var/www/html/test » touch blah.html
touch: cannot touch 'blah.html': Permission denied
id
/var/www/html/test » id -Gn
ejaz
ce qui est compréhensible puisque ejaz
est le groupe primaire.
Mais Si je su
comme ejaz
, je suis en mesure de modifier le fichier dans un terminal et dans tout programme lancé de cette instance de terminal particulière
Pourquoi ne puis-je pas éditer les fichiers tout à coup et comment pouvais-je les éditer auparavant? Tout ce que je faisais depuis hier était d'exécuter la mise à niveau appropriée d'Ubuntu.
Toute aide sera fortement appréciée.
Merci d'avoir lu.
Sudo mount
~ » Sudo mount
[Sudo] password for ejaz:
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=4021496k,nr_inodes=1005374,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=808412k,mode=755)
/dev/sda1 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/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
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/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
fusectl on /sys/fs/Fuse/connections type fusectl (rw,relatime)
/var/lib/snapd/snaps/core_4917.snap on /snap/core/4917 type squashfs (ro,nodev,relatime)
/var/lib/snapd/snaps/core_4650.snap on /snap/core/4650 type squashfs (ro,nodev,relatime)
/var/lib/snapd/snaps/core_4830.snap on /snap/core/4830 type squashfs (ro,nodev,relatime)
/var/lib/snapd/snaps/pycharm-community_62.snap on /snap/pycharm-community/62 type squashfs (ro,nodev,relatime)
/var/lib/snapd/snaps/pycharm-community_60.snap on /snap/pycharm-community/60 type squashfs (ro,nodev,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/var/lib/snapd/snaps/pycharm-community_64.snap on /snap/pycharm-community/64 type squashfs (ro,nodev,relatime)
/dev/sda4 on /mnt/SSD2 type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=808412k,mode=700,uid=1000,gid=1000)
gvfsd-Fuse on /run/user/1000/gvfs type Fuse.gvfsd-Fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
Sudo df -h
~ » Sudo df -h
Filesystem Size Used Avail Use% Mounted on
udev 3.9G 0 3.9G 0% /dev
tmpfs 790M 9.3M 781M 2% /run
/dev/sda1 82G 75G 2.3G 98% /
tmpfs 3.9G 165M 3.7G 5% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/loop0 87M 87M 0 100% /snap/core/4917
/dev/loop1 87M 87M 0 100% /snap/core/4650
/dev/loop2 87M 87M 0 100% /snap/core/4830
/dev/loop4 233M 233M 0 100% /snap/pycharm-community/62
/dev/loop3 240M 240M 0 100% /snap/pycharm-community/60
/dev/loop5 237M 237M 0 100% /snap/pycharm-community/64
/dev/sda4 136G 125G 11G 92% /mnt/SSD2
tmpfs 790M 28K 790M 1% /run/user/1000
réduire les blocs réservés à 0 n'a pas aidé
J'avais oublié de le mentionner plus tôt, mais je pense qu'il vaut la peine de mentionner que j'utilise souvent Windows 7 sur ce PC utilisant VirtualBox. Windows a accès à /var/www/html/
et /mnt/SSD2/
via le partage VirtualBox. Je suis sous Windows depuis environ un an, mais est-ce que cela aurait pu causer le fouillis des autorisations?
En ce qui concerne le rôle de Windows dans les répertoires partagés, j'utilise exclusivement Widows pour exécuter Adobe Photoshop. Windows lit donc essentiellement des images à partir de /mnt/SSD2
ou /var/www/html/html
et les stocke dans /mnt/SSD2/*
. Non La manipulation de fichiers volumineux s'effectue sous Windows sur des répertoires partagés, par exemple, la compression de répertoires, l'extraction de fichiers compressés, le déplacement de répertoires, la définition d'autorisations, etc.
Le texte flou est du modèle suivant.
/var/www/html/magento_site_1
/var/www/html/magento_site_1/var/session/sess_xxxxxxxxxxxxxxxxxxxxxxxxxx
/var/www/html/magento_site_1
/var/www/html/magento_site_1/var/session/sess_xxxxxxxxxxxxxxxxxxxxxxxxxx
/var/www/html/magento_site_1
/var/www/html/magento_site_1/var/session/sess_xxxxxxxxxxxxxxxxxxxxxxxxxx
/var/www/html/magento_site_1
/var/www/html/magento_site_1/var/session/sess_xxxxxxxxxxxxxxxxxxxxxxxxxx
....
avec xxxxxxxxxxxxxxxxxxxxxxxxxx
étant une chaîne aléatoire. La capture d'écran est la sortie complète.
Sortie de
cd /var/www/html/test
Sudo trace-cmd record -o /tmp/trace.dat -e all touch blah.html
cd /tmp
run trace-cmd report
J'ai laissé mon ordinateur allumé toute la nuit pour télécharger des fichiers dans /mnt/SSD2
sur le SSD unique de mon ordinateur et je suis revenu à cela le lendemain matin.
Lors du redémarrage, j'ai reçu une invite de commande busybox
initramfs
où exécuter fsck /dev/sda1/
m'a permis d'utiliser à nouveau mon PC, mais est-ce lié aux problèmes d'autorisations que j'ai? Est-ce que mon SSD est en train de mourir? S'agit-il du noyau nouvellement installé qui a été installé à l'aide de Sudo apt upgrade
peu de temps avant le début du problème d'autorisations?
Préface: Je ne connais rien aux instantanés.
Une option standard pour les systèmes de fichiers ext consiste à réserver 5% de l'espace à la racine sur /
Donc, il me semble que /var/www/html/
fait partie de la partition racine, qui n'a plus que 2% d'espace libre, en regardant la sortie de df
. En option standard, Linux conservera 5% de votre espace de partition de /
pour la racine. Cela expliquerait pourquoi vous ne pouvez pas éditer avec votre compte utilisateur, mais avec su
.
Pour vérifier si tel est vraiment le cas, vous pouvez utiliser tune2fs
pour voir le nombre de blocs réservés que vous avez.
Sudo tune2fs -l /dev/sda1
regardez si Reserved block count:
est supérieur à 0.
Reserved block count: 3034088
Vous voudrez peut-être modifier ceci, en tant que solution à court terme, par exemple, à 1%
Sudo tune2fs -m 1 /dev/sda1
ou avec -r
pour le nombre de blocks
(peut également être réglé sur 0)
Mais ce serait une bonne idée de laisser les 5% pour root et de déplacer vos fichiers de données vers une partition séparée.
Voici une bonne explantation expliquant pourquoi c'est une bonne idée.
Autres manières de gagner rapidement un espace de fichiers sur /
, si vous n'avez pas de partitions séparées pour /var
, /home
, etc.:
Sudo apt-get update && Sudo apt-get autoremove
Cela ne s'appliquera pas à 100% pour vous, mais c'est lié, et nous espérons vous diriger dans la bonne direction. Comme vous le dites si bien, je suppose que le problème concerne les dossiers partagés de Virtualbox. Fondamentalement, les dossiers accédés à partir de 2 systèmes d’exploitation différents, chacun avec son propre système de fichiers/autorisations, et puisque vous ne pouvez appliquer ni l’un ni l’autre ni perdre tout accès de l’autre ...
Ouais, Virtualbox essaie probablement de marcher sur la corde raide entre les deux, sans tomber des deux côtés.
Quoi qu'il en soit, les références que j'ai trouvées sont à l'opposé de votre configuration, hôte Windows et invité Ubuntu. Mais le même genre d'autorisations de manigances.
hôte Windows, invité Ubuntu, problèmes d’autorisation, avec solution