# [gelöst]emerge --sync geht nicht mehr: Permission denied

## Christian99

Hallo, ich habe ein kleines Problem mit meinen emerge --sync: Anscheinend hab ich nicht die berechtigung, dateien im tree zu ändern ich bekomme immer massenweise solche fehlermeldungen:

```
rsync: rename "/usr/portage/sci-visualization/veusz/.veusz-1.5.ebuild.f7jGlu" -> "sci-visualization/veusz/veusz-1.5.ebuild": Permission denied (13)

rsync: delete_file: unlink(sys-apps/parted/.parted-2.2.ebuild.iQA5qq) failed: Permission denied (13)

rsync: delete_file: unlink(sys-apps/parted/.parted-2.2.ebuild.H5FTTf) failed: Permission denied (13)

rsync: delete_file: unlink(sys-apps/parted/.parted-2.2.ebuild.FI3eMH) failed: Permission denied (13)

rsync: delete_file: unlink(sys-apps/parted/.parted-2.2.ebuild.AFUvzQ) failed: Permission denied (13)

rsync: delete_file: unlink(sys-apps/parted/.parted-2.2.ebuild.9B6tZs) failed: Permission denied (13)

rsync: delete_file: unlink(sys-apps/parted/.parted-2.2.ebuild.8AFTzy) failed: Permission denied (13)

rsync: delete_file: unlink(sys-apps/parted/.parted-2.2.ebuild.2YbeKP) failed: Permission denied (13)

```

anscheinend läd er die neuen dateien jedes mal runter, aber das umbenennen geht nicht. der befehl wird mit "sudo" ausgeführt. ich hab schon gelesen, dass "chown portage:portage" angewand auf den tree helfen soll, aber hier nicht.. das löschen des gesamten trees hilft, da dann alle dateien neu geholt werden, was scheinbar problemlos geht, aber danach bei updates ist das selbe probleme wieder.

Erst hab ich vermutet, dass es an meinen sqfs/aufs kombination für den tree liegt, aber inzwischen hab ich wieder den standard für den tree hergestellt, so dass er jetzt wieder unter "/usr/portage" auf einem ext4 dateisystem liegt. "per hand" kann ich aber alles im tree machen was ich will (mit sudo). kann mir da jemand wieterhelfen?

schöne grüße

ChristianLast edited by Christian99 on Wed Jun 02, 2010 9:44 am; edited 1 time in total

----------

## Jimini

Schau mal hier nach, da hatte jemand das gleiche Problem. Hast du schonmal versucht, den Portage Tree einfach neu reinzuziehen?

MfG Jimini

----------

## Christian99

ja, ich hab sowohl den tree gelöscht, als auch ein chown gemacht. beides nix geholfen, siehe oben.

----------

## Genone

Beim chown auch nicht das -R vergessen?

Auch mal ohne sudo probiert?

Und was sagt `emerge --info | grep FEATURES`?

----------

## Christian99

beim chown, das ich ausgeführt hab mars mit -R, habs nur hier vergessen.

emerge --info|grep FEATURES

```
FEATURES="assume-digests candy ccache distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch"
```

ich nehme an du willst auf userfetch hinaus. da hab ich auch schon dran gedacht, und in der make.conf nachgeschaut, wo es nicht drin steht. heißt das, dass emerge userfetch als standardoption verwendet? seit wann?

emerge --sync ohne sudo:

```
emerge --sync

superuser access is required... adding --pretend to options

emerge: The 'sync' action does not support '--pretend'.
```

EDIT: hab bei FEATURES in der make.conf "-userfetch" hinzugefügt, hilt auch nicht.

----------

## Genone

Ne, hab nach usersync geguckt, userfetch ist was anderes.  Und mit 'ohne sudo' meinte ich eine "echte" root-Shell, sprich als root einloggen oder mit `su -` wechseln.

Ansonsten wie sehen denn die Rechte der betroffenen Dateien und v.a. der übergeordneten Verzeichnisse aus?

----------

## Christian99

achso, userfetch und usersync gibts beides...

wenn ich mit su wechsle macht das auch keinen unterschied.

die berechtigungen der verzeichnise sind drwxr-xr-x bzw -rwxr-xr-x bei den dateien, ich hab zwar nicht jede einzelne nachgeschaut, aber da ich gestern den kompletten tree mit emerge --sync geholt habe wird das schon passen (hoffe ich)

----------

## Christian99

*push*

----------

## 69719

Haste mal das Dateisystem überprüft?

----------

## Christian99

zuletzt vor 2 oder 3 bootups, aber da ging es schon nicht mehr. außerdem kann ich alle dateioperationen "per Hand" ganz normal durchführen. Und ich hatte das Anfangs auf einer squash/aufs kombination. da haben die probleme angefangen, und daraufhin hab ich es auf meine ganz normale systempartition umgelegt, was keine verängerung gebracht hat. Deswegen würd ich dateisystem ausschließen.

----------

## 69719

Dann zeig was folgendes als user root ausgibt.

```

mount

ls -ld /usr/portage

ls -ld /usr/portage/sci-visualization

ls -ld /usr/portage/sci-visualization/veusz

ls -ld /usr/portage/sci-visualization/veusz/veusz-1.5.ebuild

```

Und die ausgabe von "emerge --sync", ersetzt durch "id" als

entsprechnenden user. Sprich, wenn du "sudo emerge --sync" verwendest

oder etwas anderes, dann "sudo id".

----------

## Christian99

also:

```
mount

/dev/sda5 on / type ext4 (rw,noatime)

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755)

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

/dev/sda1 on /boot type ext2 (rw,noatime)

/dev/sdc3 on /home type ext4 (rw,noatime)

none on /var/tmp/portage type tmpfs (rw,nr_inodes=1M,size=2G)

/dev/sdb5 on /mnt/net type ext3 (ro,noatime)

shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)

binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

/dev/sr0 on /mnt/cdrom1 type iso9660 (ro,noexec,nosuid,nodev)

```

```
ls -ld /usr/portage 

drwxr-xr-x 163 portage portage 4096 24. Mai 19:08 /usr/portage

```

```
ls -ld /usr/portage/sci-visualization

drwxr-xr-x 33 root root 4096 24. Mai 19:07 /usr/portage/sci-visualization

```

```
ls -ld /usr/portage/sci-visualization/veusz 

drwxr-xr-x 3 root root 4096 18. Mai 15:37 /usr/portage/sci-visualization/veusz

```

```
ls -ld /usr/portage/sci-visualization/veusz/veusz-1.5.ebuild 

-rw-r--r-- 1 root root 1256 18. Mai 15:37 /usr/portage/sci-visualization/veusz/veusz-1.5.ebuild

```

es macht auch keinen unterschied, wenn der besitzer der dateien portage:portage ist. Die Ausgabe von "sudo emerge --sync" siehst du beispielhaft oben im ersten post, wenn du wirklich alles sehn willst, was ja ewig lang ist, dann kann ich das auch posten.

----------

## Genone

a) du benutzt nicht zufällig SeLinux oder irgend ein anderes Sicherheitssystem, das root Rechte entzieht?

b) unter welchem User wird rsync ausgeführt? (top sollte das sagen können)Last edited by Genone on Tue May 25, 2010 1:14 pm; edited 1 time in total

----------

## Christian99

a) nein, kein selinux oder ähnliches

b) rsync --recursive läuft als root (laut htop)

----------

## Genone

Ok, dann bin ich mit meinem Latein auch langsam am Ende. Auf einem normalen Linux System sollte root eigentlich keine "Permission denied" Fehler kriegen können (von ein paar Spezialfällen wie /proc abgesehen)

----------

## 69719

 *Genone wrote:*   

> Ok, dann bin ich mit meinem Latein auch langsam am Ende. Auf einem normalen Linux System sollte root eigentlich keine "Permission denied" Fehler kriegen können (von ein paar Spezialfällen wie /proc abgesehen)

 Oder das Filesystem hat einen defekt, da kenn ich das Problem her und konnte auch immer schön händisch gefixt werden.

Was sagt denn?

```

tune2fs -l /dev/sda5

```

----------

## Christian99

```
sudo tune2fs -l /dev/sda5                             

tune2fs 1.41.9 (22-Aug-2009)                                             

Filesystem volume name:   <none>                                         

Last mounted on:          /                                              

Filesystem UUID:          00fdcba2-8f24-4404-9161-4ba484bbd376           

Filesystem magic number:  0xEF53                                         

Filesystem revision #:    1 (dynamic)                                    

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize                                                                                                                          

Filesystem flags:         signed_directory_hash                                                                                                     

Default mount options:    (none)                                                                                                                    

Filesystem state:         clean                                                                                                                     

Errors behavior:          Continue                                                                                                                  

Filesystem OS type:       Linux                                                                                                                     

Inode count:              3276800

Block count:              13107016

Reserved block count:     655350

Free blocks:              6581649

Free inodes:              2486170

First block:              0

Block size:               4096

Fragment size:            4096

Reserved GDT blocks:      1020

Blocks per group:         32768

Fragments per group:      32768

Inodes per group:         8192

Inode blocks per group:   512

Flex block group size:    16

Filesystem created:       Mon Mar 22 13:51:55 2010

Last mount time:          Tue May 18 23:09:33 2010

Last write time:          Mon May 17 08:59:17 2010

Mount count:              3

Maximum mount count:      38

Last checked:             Mon May 17 08:59:17 2010

Check interval:           15552000 (6 months)

Next check after:         Sat Nov 13 07:59:17 2010

Lifetime writes:          273 GB

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               256

Required extra isize:     28

Desired extra isize:      28

Journal inode:            8

First orphan inode:       1507925

Default directory hash:   half_md4

Directory Hash Seed:      1367c67f-a382-41d2-b846-50de0c14de9d

Journal backup:           inode blocks
```

ich kann aber nicht so recht glauben, dass es am dateisystem liegt, sondern an portage. denn wie schon gesagt, der portagetree ist quasi nur zur fehlersuche auf der "/" partition. vorher war es auf einer anderen (sqfs/aufs). UND: per hand (d.h. "sudo mv ...") geht alles, was vorher nicht geht.

----------

## ChrisJumper

Hallo Christian99,

ich würde versuchen den Tree zu entfernen und ihn anschließend mit einem portage-latest.tar.bz2 Snapshot wieder herzustellen, so wie man das macht wenn man ein System neu installiert.

Wenn du ein Overlay/Layman verwenderst achte darauf das du beim Löschen von /usr/portage nicht auch den Unterordner /usr/portage/local gleich mit entfernst.

Gruß

----------

## Christian99

hab ich auch schon gemacht. entweder löschen und portage-latest reinkopieren, oder löschen und emerge --sync. beides geht einmal, aber beim nächsten mal emerge --sync wieder genau das gleiche.

----------

## 69719

Und wie sieht es aus wenn du es per hand anschupst?

```

rsync --verbose $(portageq envvar PORTAGE_RSYNC_OPTS SYNC PORTDIR)

```

----------

## Christian99

läuft, ich bin sprachlos....

jetzt kann ich wenigstens syncen, ohne den ganzen tree löschen zu müssen. aber wieso portage das nicht kann....

----------

## 69719

 *Christian99 wrote:*   

> läuft, ich bin sprachlos....
> 
> jetzt kann ich wenigstens syncen, ohne den ganzen tree löschen zu müssen. aber wieso portage das nicht kann....

 

Wenn das geht und mittels emerge --sync nicht, müßte es bedeuten, dass portage den rsync befehl nicht als root anschups.

Eventuell mal portage und rsync neu installieren?

----------

## Christian99

portage hab ich bereits in 3 verschieden versionen probiert: 2.1.7.17, 2.1.7.3, 2.2-rc67. bei allen das gleiche. und rsync reemergen hat auch nix gebracht.

gibts denn irgendeine Einstellung die portage dazu veranlassen könnte, rsync nicht als root auszuführen? ich kann mich zwar nicht dran erinnern, dass ich da was umgestellt habe, aber wer weiß...

----------

## Christian99

ich pushe nochmal, im prinzip gehts zwar mit dem workaround, aber seltsam finde ich das schon

----------

## Genone

Wie schon gesagt, die Einstellung damit rsync nicht als root läuft wäre FEATURES=usersync, was du ja aber nicht aktiviert hast. Und ich hatte ja extra nochmal gefragt als welcher User rsync läuft, insofern kann das eigentlich nicht das Problem sein. Hab aber auch keine Ahnung was es sonst sein könnte, ohne das jetzt komplett zu analysieren (was aus der Ferne ohnehin nur schwer möglich ist).

----------

## Christian99

ich hab jetzt nochmal mit ps geschaut, während ein emerge -sync läuft:

```
root     12422 11677  0 19570  6872   1 23:17 pts/3    00:00:02 rsync --recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --verbose --progress rsync://193.1.193.64/gentoo-portage/ /usr/portage/tree/official

root     12423 12422  0 29317  5040   1 23:17 pts/3    00:00:00 rsync --recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --verbose --progress rsync://193.1.193.64/gentoo-portage/ /usr/portage/tree/official

```

also: wenn ich das richtig sehe läuft der rsync-prozess als user root, was ja so sein soll. ein bisschen erstaunt bin ich, das rsync zweimal läuft. soll das so sein? wenn ich den Ellenlangen rsync befehl per hand ausführe (mit sudo natürlich) geht wieder alles.

hat es eventuell sinn einen bugreport aufzumachen? ich hab ja eigentlich doch recht wenig infos....

EDIT: gegen ende von dem per hand ausgeführten befehl gabs doch ein paar probleme:

rsync: readlink_stat("/metadata/cache/kde-base/kdm-4.3.5-r1" (in gentoo-portage)) failed: Stale NFS file handle (116)

ich hab aber kein nfs im portage tree. es ist (inzwischen wieder) squashfs/aufs. wieso gibts da nen nfs-fehler?

----------

## Christian99

Ok, gefunden: es lag an libtrash.

Ich habe das zwar schon länger, habe aber kürzlich LD_PRELOAD von .bashrc nach /etc/profile umgezogen.

Ich versteh aber immer noch nicht wieso es bei "emerge --sync" nicht geht, aber bei "rsync ..." gehts. bei beiden befehlen müsste doch libtrash geladen werden, oder nicht?

----------

## disi

Lol, ich verfolge diesen Beitrag schon laenger weil es mir bekannt vorkam  :Very Happy:  Leider bin ich darauf nicht gekommen :/

Bei mir war es so, das ich libtrash installiert hatte und gleich anschliessend Probleme auftraten. Also wieder rausgeschmissen und Problem war weg.

Wenn du es als User benutzen willst, dann nicht Systemweit sondern in der .profile im home directory  :Wink: 

----------

## Genone

 *Christian99 wrote:*   

> Ich versteh aber immer noch nicht wieso es bei "emerge --sync" nicht geht, aber bei "rsync ..." gehts. bei beiden befehlen müsste doch libtrash geladen werden, oder nicht?

 

Die Frage wäre erstmal was genau das Problem mit libtrash war, evtl. war es unter emerge vielleicht doppelt geladen oder so (müsste man im Detail schauen). Aber generell sollte man mit LD_PRELOAD sehr vorsichtig sein. Insbesondere im globalen Kontext kriegt man da schnell unerwünschte Nebenwirkungen deren Ursache man nur schwer lokalisieren kann (wie gerade wieder gesehen).

----------

## Christian99

das problem war, dass /usr ein geschütztes verzeichnis ist, und dass alle rm/mv aufrufe dort von libtrash mit permission denied beantwortet werden. Das soll eigentlich auch so sein. Was aber seltsam ist:

```
sudo echo $LD_PRELOAD

/usr/lib64/libtrash.so
```

also wird libtrash geladen. oder übernimmt sudo das von der aufrufenden shell? 

denn wenn ich mit sudo -s zu root wechsle, dann ist LD_PRELOAD leer:

```
sudo -s

echo $LD_PRELOAD

emerge --info|grep LD_PRELOAD

LD_PRELOAD="/usr/lib64/libtrash.so"

```

also läd sich emerge (python) nochmal extra enviromentvariablen, kann das sein?

----------

## 69719

Variablen werden immer vor dem ausführen durch die entsprechenden Werte in der aktuellen Umgebung ersetzt, nicht erst nach einem sudo oder sonstiges.

----------

## Christian99

es geht ja nicht ums ERsetzen, sondern ums GEsetzt werden der variablen. wiso ist in meiner root-umgebung LD_PRELOAD leer, obwohl es in /etc/profile steht, wenn ich aber emerge aus der selben root-umgebung wieder aufrufe ist es gesetzt?

----------

## 69719

 *Christian99 wrote:*   

> es geht ja nicht ums ERsetzen, sondern ums GEsetzt werden der variablen. wiso ist in meiner root-umgebung LD_PRELOAD leer, obwohl es in /etc/profile steht, wenn ich aber emerge aus der selben root-umgebung wieder aufrufe ist es gesetzt?

 

Wenn

```

sudo echo $LD_PRELOAD 

```

verarbeitet wird, so wid LD_PRELOAD duch den entsprechenden Wert ersetzt.

```

man bash

/INVOCATION

...

When  bash  is  invoked  as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists.

...

```

Das sollte deine Frage beantworten, stand auch die Tage schon im Board zur Diskussion.

Emerge wird wohl demnach ein source machen, könntest du mal mittels strace verfolgen.

----------

## Christian99

 *Quote:*   

> Wenn
> 
> Code:
> 
> sudo echo $LD_PRELOAD
> ...

 

klar, mein fehler.

 *Quote:*   

> Code:
> 
> man bash
> 
> /INVOCATION
> ...

 

ja, fast klar: wann ist eine bash eine interactive login-shell? wenn ich mich an ttyX einlogge, dann wahrscheinlich auf jeden fall. aber wenn ich unter x eine terminalsitzung öffne (konsole in meinen Fall) ist da bash dann eine loginshell? ich hätte vermutet, dass nicht, es wird aber LD_PRELOAD gesetzt. und bash wird nicht mit "--login" parameter gestartet.

Eventuell sollte ich noch sagen das LD_PRELOAD in /etc/profile.env gesetzt, nich in /etc/profile. hab gerade nochmal nachgeguckt.

ist mit der datei was anderes? ich hab nur gesehn, dass sie von /etc/profile aufgerufen wird und portage ruft /etc/profile.env direkt auf, ohne /etc/profile.

Allerdings: wenn ich konsole strace kann ich nichts sehen, dass entweder /etc/profile oder /etc/profile.env geöffnet werden. wo kommt dann LD_PRELOAD her? von X? und wieso wird es dann nicht an die root-shell weitergegeben?

----------

## Genone

 *Christian99 wrote:*   

> Allerdings: wenn ich konsole strace kann ich nichts sehen, dass entweder /etc/profile oder /etc/profile.env geöffnet werden. wo kommt dann LD_PRELOAD her?

 

Vermutlich vom aufrufenden Prozess, da ich davon ausgehe dass LD_PRELOAD exportiert ist.

 *Quote:*   

> und wieso wird es dann nicht an die root-shell weitergegeben?

 

hängt davon ab wie die root-Shell gestartet wird: sudo z.B. setzt standardmässig viele (alle?) Umgebungsvariablen zurück bevor es einen Prozess startet.

----------

## Christian99

ahja, ich hab auch mal in der manpage von sudo geschaut, und ja da werden einige variablen zurüchgesetzt. Wie gesagt, ich verwende libtrash schon länger, und wenn ich was an systemdateien mit sudo gemacht habe, ist mir schon aufgefallen, dass da libtrash nicht verwendet wird. deswegen bin ich auch lange nicht drauf gekommen, dass plötzlich beim emerge --sync libtrash seine finger im spiel hat. Stellt sich eigentlich nur die frage, wieso das beim syncen so war, aber nicht wenn ich ein paket emerged habe. Aber manche geheimnisse wird wohl selbst Linux für sich behalten  :Smile: 

----------

## Genone

Wäre möglich dass das durch die Sandbox (die ja auch über LD_PRELOAD geladen wird) ausgehebelt wird.

----------

## Christian99

oh je, word ja immer komplizierter....

aber nachdem nun auch beim installieren des neuesten wine deswegen probleme auftraten, bin ich nun wieder dazu übergegangen, LD_PRELOAD in die .bashrc zu schreiben, und nicht in die profile.env. Das gibt denk ich wesentlich weniger probleme.

Dann noch mal danke an alle, die mir bei der fehlersuche geholfen haben!!

----------

