web-dev-qa-db-fra.com

Tout à coup, je reçois des erreurs d'autorisation

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 rootadmcdromSudodipwww-dataplugdevlpadminsambasharekismetwiresharkdocker. 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.

Sortie de la commande groups

~ » groups ejaz                                                                                                                                                              
ejaz : ejaz root adm cdrom Sudo dip www-data plugdev lpadmin sambashare kismet wireshark docker

Autorisations pour test site

/var/www/html » l | grep test
drwxrwxr-x  2 www-data www-data 4.0K Apr  9  2017 test

Mais toute édition entraîne des erreurs d'autorisation

/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

Sortie de la commande 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

Question

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.

Mise à jour # 1

Sortie de la commande 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)

Sortie de la commande 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

Mise à jour # 2

enter image description here

Mise à jour # 3

réduire les blocs réservés à 0 n'a pas aidé

enter image description here

Mise à jour # 4

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.

Mise à jour # 5

enter image description here

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.

Mise à jour # 6

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

x

Mise à jour 7

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.

enter image description here

Lors du redémarrage, j'ai reçu une invite de commande busyboxinitramfs 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?

2
Ejaz

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.:

  • nettoyez vos maisons d'utilisateurs
  • supprimer les anciens fichiers journaux
  • supprime les anciens paquets/noyaux avec Sudo apt-get update && Sudo apt-get autoremove
5
Robert Riedl

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

0
Lubo Diakov