Ordner bzw. Datei lässt sich nicht löschen...


Jojo1965
Go to solution Solved by Jojo1965,

Recommended Posts

Hallo zusammen, ich habe noch ein Fragment meiner Einrichtungs- und Ausprobierphase entdeckt, die Datei bzw. der gesamte Ordner lässt sich aber leider nicht löschen, wer weiß Abhilfe? Der aktuelle Ordner "Appdata" befindet sich definitiv nicht auf der Disk 5 sondern auf dem SSD Cache.


/UNRAID/disk5/appdate/binhex-preclear/home/.icons/BLACK-Ice-Numix-Flat/128 (Datum 11.01.2021)


Danke

Jojo

 

Link to comment

Den Ordner /UNRAID habe ich angelegt um "einfacher" direkt auf alle Laufwerke zu kommen, war glaube ich in einem Tutorial von SpaceInvader One so vorgekommen...

 

 

Hier die Ausgabe von "mount":

root@Unraid-Tower:~# mount
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
tmpfs on /var/log type tmpfs (rw,size=128m,mode=0755)
/dev/sda1 on /boot type vfat (rw,noatime,nodiratime,flush,dmask=77,fmask=177,shortname=mixed)
/boot/bzmodules on /lib/modules type squashfs (ro)
/boot/bzfirmware on /lib/firmware type squashfs (ro)
hugetlbfs on /hugetlbfs type hugetlbfs (rw)
overlay on /lib/modules type overlay (rw,lowerdir=/lib/modules,upperdir=/var/local/overlay/lib/modules,workdir=/var/local/overlay-work/lib/modules)
overlay on /lib/firmware type overlay (rw,lowerdir=/lib/firmware,upperdir=/var/local/overlay/lib/firmware,workdir=/var/local/overlay-work/lib/firmware)
/mnt on /mnt type none (rw,bind)
tmpfs on /mnt/disks type tmpfs (rw,size=1M)
tmpfs on /mnt/remotes type tmpfs (rw,size=1M)
nfsd on /proc/fs/nfs type nfsd (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
/dev/md1 on /mnt/disk1 type xfs (rw,noatime)
/dev/md2 on /mnt/disk2 type xfs (rw,noatime)
/dev/md3 on /mnt/disk3 type xfs (rw,noatime)
/dev/md4 on /mnt/disk4 type xfs (rw,noatime)
/dev/md5 on /mnt/disk5 type xfs (rw,noatime)
/dev/md6 on /mnt/disk6 type xfs (rw,noatime)
/dev/md7 on /mnt/disk7 type xfs (rw,noatime)
/dev/md8 on /mnt/disk8 type xfs (rw,noatime)
/dev/nvme1n1p1 on /mnt/cache type btrfs (rw,noatime,space_cache=v2,discard=async)
shfs on /mnt/user0 type fuse.shfs (rw,nosuid,nodev,noatime,allow_other)
shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,allow_other)
/mnt/cache/system/docker/docker.img on /var/lib/docker type btrfs (rw,noatime,space_cache=v2)

Link to comment
1 hour ago, Jojo1965 said:

Den Ordner /UNRAID habe ich angelegt um "einfacher" direkt auf alle Laufwerke zu kommen, war glaube ich in einem Tutorial von SpaceInvader One so vorgekommen...

Klingt komisch. Der Ordner ist jedenfalls nicht persistent, sondern im RAM und beim Neustart daher weg. 

Link to comment
On 1/31/2022 at 7:15 PM, hawihoney said:

 

Nach einem Neustart müsste das weg sein.

 

 

On 1/31/2022 at 8:02 PM, mgutt said:

Klingt komisch. Der Ordner ist jedenfalls nicht persistent, sondern im RAM und beim Neustart daher weg. 

 

Das ist so nicht korrekt, ein Neustart verändert nichts am aktuellen Zustand, /UNRAID ist dann weiterhin verfügbar.

Link to comment
On 2/2/2022 at 12:02 PM, hawihoney said:

 

Wir reden hier über den Root-Folder /UNRAID auf dem Server, oder? Poste mal die Ausgabe dieses Befehls auf der Unraid Konsole:

 

ls -lisa /

 

 

Gerne, für mich natürlich böhmische Dörfer, bin "nur" Anwender und kein Spezialist in diesen Dingen.

 

root@Unraid-Tower:~# ls -lisa /
total 12
      1 0 drwxr-xr-x  20 root   root   460 Jan 31 11:52 ./
      1 0 drwxr-xr-x  20 root   root   460 Jan 31 11:52 ../
2944286 4 -rw-------   1 root   root    12 Feb  1 09:59 .bash_history
  91308 4 -rw-rw-rw-   1 root   root   180 Jan 28 01:31 .wget-hsts
    340 0 drwxr-xr-x   2 root   root  3700 Jan 21  2020 bin/
      1 4 drwx------  10 root   root  4096 Jan  1  1970 boot/
      1 0 drwxr-xr-x  15 root   root  3960 Jan 27 23:12 dev/
   5528 0 drwxr-xr-x  54 root   root  3020 Feb  2 11:46 etc/
    627 0 drwxr-xr-x   2 root   root    40 Apr  7  2021 home/
   3125 0 drwxr-xr-x   2 root   root     0 Jan 27 23:09 hugetlbfs/
   6535 0 lrwxrwxrwx   1 root   root    10 Apr  7  2021 init -> /sbin/init*
    528 0 drwxr-xr-x   8 root   root   160 Apr  7  2021 lib/
    887 0 drwxr-xr-x   5 root   root  3520 Apr  7  2021 lib64/
    886 0 drwxr-xr-x  15 root   root   300 Jan 27 23:12 mnt/
  14823 0 drwx--x--x   3 root   root    60 Jan 27 23:13 opt/
      1 0 dr-xr-xr-x 367 root   root     0 Jan 27 23:09 proc/
      4 0 drwx--x---   2 root   root   180 Jan 27 23:22 root/
    524 0 drwxr-xr-x  12 root   root   340 Jan 28 01:39 run/
    628 0 drwxr-xr-x   2 root   root  5220 Jan 27 23:10 sbin/
      1 0 dr-xr-xr-x  13 root   root     0 Jan 27 23:09 sys/
   6524 0 drwxrwxrwt  16 nobody users  360 Feb  4 13:07 tmp/
   1121 0 drwxr-xr-x  15 root   root   360 Jan 31 11:52 usr/
     10 0 drwxr-xr-x  15 root   root   340 Jan 27 23:09 var/

Link to comment
5 hours ago, Jojo1965 said:

ls -lisa /

 

Ok, genau das hatte ich vermutet. /UNRAID ist nicht das Wurzelverzeichnis von Unraid selbst sondern nur auf einer der Platten - das dahinter dann .../disk5/... steht zeigt, dass irgendjemand bzw. irgendetwas falsch konfiguriert ist bzw. falsch kopiert wurde.

 

Und da dieser Ordner scheinbar nicht zu löschen ist, greift wohl immer noch eine fehlerhafte Konfiguration.

 

1.) Mach mal bitte Screenshots von den Docker Einstellungen und, wenn Du VMs nutzt, den VM Einstellungen. Damit bekommen wir heraus, ob für die Zukunft alles korrekt eingestellt ist:

 

Unbenannt.thumb.jpg.ba967b04043f139593af6561bfb14ed9.jpg

 

2.) Mach einen Screenshot von der Docker Container Übersicht. Damit bekommen wir heraus, ob ein Container falsch konfiguriert ist. Wichtig sind hier die Pfade, Also alle blauen Pfeile nach unten aufklappen:

 

Unbenannt.thumb.jpg.1f485880eed0b553938139c232e0868c.jpg

 

Edited by hawihoney
Link to comment
20 hours ago, hawihoney said:

 

Ok, genau das hatte ich vermutet. /UNRAID ist nicht das Wurzelverzeichnis von Unraid selbst sondern nur auf einer der Platten - das dahinter dann .../disk5/... steht zeigt, dass irgendjemand bzw. irgendetwas falsch konfiguriert ist bzw. falsch kopiert wurde.

 

Und da dieser Ordner scheinbar nicht zu löschen ist, greift wohl immer noch eine fehlerhafte Konfiguration.

 

1.) Mach mal bitte Screenshots von den Docker Einstellungen und, wenn Du VMs nutzt, den VM Einstellungen. Damit bekommen wir heraus, ob für die Zukunft alles korrekt eingestellt ist:

 

Unbenannt.thumb.jpg.ba967b04043f139593af6561bfb14ed9.jpg

 

2.) Mach einen Screenshot von der Docker Container Übersicht. Damit bekommen wir heraus, ob ein Container falsch konfiguriert ist. Wichtig sind hier die Pfade, Also alle blauen Pfeile nach unten aufklappen:

 

Unbenannt.thumb.jpg.1f485880eed0b553938139c232e0868c.jpg

 

 

Danke für deine Hilfe! Ich verwende keine VMs. 

 

 

Screenshot 2022-02-05 101151.png

Screenshot 2022-02-05 101231.png

Link to comment
1 hour ago, Jojo1965 said:

Ich verwende keine VMs. 

 

Es sind nicht alle blauen Pfeile aufgeklappt, deshalb unter Vorbehalt:

 

Du nutzt in den Docker Containern /UNRAID bzw. /Unraid als Mapping zum Host (dem Server). Das solltest Du tunlichst nicht löschen. Würdest Du /UNRAID löschen können dann wäre Dein Server leer, da /mnt gemappt ist.

 

Was /UNRAID/disk5/appdata angeht. Wie gesagt, unter Vorbehalt: Ich denke das kann weg. Aber nur appdata - nicht disk5 und nicht /UNRAID. Vielleicht guckt noch ein zweites Paar Augen drauf. 

 

Edited by hawihoney
  • Like 1
Link to comment
8 minutes ago, hawihoney said:

Was /UNRAID/disk5/appdata angeht. Wie gesagt, unter Vorbehalt: Ich denke das kann weg. Aber nur appdata - nicht disk5 und nicht /UNRAID. 

 

Darum geht es mir ja, ich möchte den Ordner "appdata/binhex-preclear/home/.icons/BLACK-Ice-Numix-Flat/128" auf Disk 5 gerne löschen. Krusader tut dies aber nicht.

Link to comment
5 minutes ago, Jojo1965 said:

ich möchte den Ordner "appdata/binhex-preclear/home/.icons/BLACK-Ice-Numix-Flat/128" auf Disk 5 gerne löschen. Krusader tut dies aber nicht.

 

ich würde mal sagen da krusader von binhex nicht als root läuft kannst du diese Dateien aktuell nicht löschen

 

Ansatz a: starte krusader Docker als root, UID 0, GID 0 ... dann sollte das auch mit krusader gehen, A C H T U N G .. jetzt geht alles, AUFPASSEN wie @hawihoney beschrieben hat ... nicht diskx löschen oder geschweige darüber etwas löschen ... ab ..../appdata/... danach wieder umstellen auf 99 100

 

Ansatz b: unraid terminal, so würde ich es machen ;) rm -R /mnt/disk5/appdata

 

so wäre der KOMPLETTE appdata Ordner von disk5 weg ... wenn du NUR den binhex-preclear entfernen willst, eins weiter ansetzen

rm -R /mnt/disk5/appdata/binhex-preclear ... so wäre .../binhex-preclear samt Inhalt weg.

 

du löschst so NUR was in appdata oder darunter auf disk5 liegt, VORHER schauen, überlegen, entsprechend ausführen ...

 

sinnvoll falls noch andere Ordner, ... in /appdata auf disk5 liegen

 

AUF EIGENE GEFAHR ;)

 

Link to comment
1 hour ago, Jojo1965 said:

Den Ordner /UNRAID habe ich mit Krusader angelegt

 

Nur zur Korrektur: Den Ordner hast Du nicht _mit_ Krusader angelegt, sondern diesen Ordner hast Du in den Docker Container Settings _für_ Krusader angegeben. Dadurch wurde dass Mapping "/mnt" (Host) --> "/UNRAID" (Container) durch das Docker Subsystem _für_ Krusader angelegt.

 

Das mag jetzt spitzfindig klingen, aber es soll aufzeigen, was auch später einmal für andere Container/VMs wichtig werden wird.

 

Wenn Du Dir Deine verschiedenen Mappings für Krusader anschaust, dann hast Du dort schon drei Mappings die mehr oder weniger das selbe ausdrücken:

 

/mnt --> /UNRAID

/mnt/user --> /MEDIA (ist eigentlich schon in /UNRAID enthalten)

/mnt/disks --> /UNASSIGNED (ist eigentlich schon in /UNRAID enthalten)

 

Wenn Du nicht unterschiedliche Berechtigungen bei den Mappings verwendest, ist einiges überflüssig.

 

Mit dem bisher erworbenen Wissen kannst Du das in Zukunft bestimmt besser organisieren. Ein Hinweis: Wenn Du damit sofort beginnst, dann wirst Du innerhalb der Container (Plex, ...) einiges anpassen müssen. Das hat zur Folge, dass Du Dich auch mit deren Eigenarten beschäftigen musst (Stichwort: Z.B. Gesehenstatus bei Plex). Also aufgepasst ...

 

Link to comment

Da ich das gar nicht leiden kann, dass Pfade in Containern anders heißen, schleife ich die immer 1:1 durch und gerade bei Krusader ganz gezielt nur /mnt/diskX bzw /mnt/poolname:

 

image.thumb.png.e3daba7ffb37c90fe00486c32df54856.png

 

Alles andere ist nur pure Verwirrung und schlussendlich auch gefährlich, wenn man nicht weiß was man tut.

 

Außerdem sieht man, dass ich den Root-Zugang auf "true" gesetzt habe. Dadurch hat man dann auch kein Rechteproblem beim Löschen.

 

PS Krusader sollte man nach der Nutzung immer stoppen. Jeder in deinem Netzwerk, der den Port errät könnte sonst deinen ganzen Server platt machen.

Link to comment
35 minutes ago, mgutt said:

Da ich das gar nicht leiden kann, dass Pfade in Containern anders heißen

 

Das ist die Pest, da gebe ich Dir 100%-ig Recht. Lustig wird es wenn Du Tools aus den Containern nutzen willst, die dann wiederum auf gemappte Pfade zugreifen. Ich nutze bestimmt ein dutzend Skripte die Tools aus MKVToolNix bzw. MakeMKV aufrufen. Man müsste dann innerhalb der Skripte die Pfade ändern.

 

Deshalb gibt es bei mir immer "Mnt: /mnt --> /mnt". Das ist Sicherheitstechnisch völlig irre, aber anders ging es nicht, weil sich die fest verdrahteten Container Settings teilweise nicht abschalten lassen. Und wenn ich noch etwas mehr hasse, dann sind das doppelte/überflüssige Einstellungen.

 

Hier Fragmente eines meiner Python Skripts, welches z.B. von /mnt nach /storage mappen müsste, da der Container MKVToolNix /storage fest vergibt. In dem Skript lese ich aus Plex über deren offizielle Web API und schreibe maschinell die Titel in die MKV Dateien. Dazu muss ich dann /mnt nach /storage übersetzen:

 

[...]
mkvtoolnix_container = "MKVToolNix"
mkvtoolnix_from = "/mnt/"     # or None
mkvtoolnix_to = "/storage/"   # or None
mkvinfo = f"docker exec {mkvtoolnix_container} /usr/bin/mkvinfo"
mkvpropedit = f"docker exec {mkvtoolnix_container} /usr/bin/mkvpropedit"
[...]
info = f' --edit info --set "title={title_new}"'                                                            
command = None
if mkvtoolnix_from and mkvtoolnix_to:
    command = f'{mkvpropedit} "{video_media_part_file.replace(mkvtoolnix_from, mkvtoolnix_to)}"{info}'
else:
    command = f'{mkvpropedit} "{video_media_part_file}"{info}'
                                                           
if command and not args.dryrun:
    result = os.popen(command).read()
    os.utime(video_media_part_file, (mkv_atime, mkv_mtime))

 

Edited by hawihoney
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.