Fix Common Problems Extended Test Meldungen

[Revan335]

9 minutes ago, mgutt said:

Tools > Docker Safe Perms

Das hab ich bereits, aber das hat leider nicht geholfen.

[mgutt]

Mach mal chmod -v 666 <file> bei einer der Dateien mit falschen Rechten. Geht das bzw was kommt für eine Fehlermeldung?

[Revan335]

14 hours ago, mgutt said:

Mach mal chmod -v 666 <file> bei einer der Dateien mit falschen Rechten. Geht das bzw was kommt für eine Fehlermeldung?

 

Einmal ein Ordner und einmal eine Datei aus dem Extended Log. Nachdem Run der beiden Befehle und dem Docker New Permissons Script und nem neuen Extended Run.

 

:~# chmod -v 777 /mnt/user/Altes\ NAS/Backup-NAS-2/USB\ Backup\ 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20200531-171501-707/backup/home/username/Bilder/Bilder
chmod: cannot operate on dangling symlink '/mnt/user/Altes NAS/Backup-NAS-2/USB Backup 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20200531-171501-707/backup/home/username/Bilder/Bilder'
failed to change mode of '/mnt/user/Altes NAS/Backup-NAS-2/USB Backup 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20200531-171501-707/backup/home/username/Bilder/Bilder' from 0000 (---------) to 0000 (---------)

:~# chmod -v 666 /mnt/user/Altes\ NAS/Backup-NAS-2/USB\ Backup\ 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20211205-223001-457/backup/home/username/Bilder/Auswahl_2015-05-31-13:27:26.jpg
mode of '/mnt/user/Altes NAS/Backup-NAS-2/USB Backup 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20211205-223001-457/backup/home/username/Bilder/Auswahl_2015-05-31-13:27:26.jpg' retained as 0666 (rw-rw-rw-)

 

 

:~# stat /mnt/user/Altes\ NAS/Backup-NAS-2/USB\ Backup\ 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20211205-223001-457/backup/home/username/Bilder/Auswahl_2015-05-31-13:27:26.jpg
  File: /mnt/user/Altes NAS/Backup-NAS-2/USB Backup 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20211205-223001-457/backup/home/username/Bilder/Auswahl_2015-05-31-13:27:26.jpg
Size: 50205           Blocks: 104        IO Block: 4096   regular file
Device: 32h/50d Inode: 648799848002915371  Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (   99/  nobody)   Gid: (  100/   users)
Access: 2021-12-31 13:11:33.103000000 +0100
Modify: 2015-05-31 13:28:01.000000000 +0200
Change: 2022-04-20 21:36:08.040124708 +0200
 Birth: -

:~# stat /mnt/user/Altes\ NAS/Backup-NAS-2/USB\ Backup\ 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20200531-171501-707/backup/home/username/Bilder/Bilder
  File: /mnt/user/Altes NAS/Backup-NAS-2/USB Backup 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20200531-171501-707/backup/home/username/Bilder/Bilder -> /home/username/Mountpoints/NAS_User/Bilder/
  Size: 40              Blocks: 0          IO Block: 4096   symbolic link
Device: 32h/50d Inode: 648799845783652882  Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (   99/  nobody)   Gid: (  100/   users)
Access: 2022-04-09 13:10:46.113651373 +0200
Modify: 2022-04-09 13:10:46.113651373 +0200
Change: 2022-04-20 20:44:21.460039940 +0200
 Birth: -

 

Edited April 20, 2022 by Revan335

[Revan335]

Hat einer noch Ideen wie man das fixen kann? Vielleicht weitere @mgutt Ideen?

[mgutt]

On 4/20/2022 at 9:47 PM, Revan335 said:

chmod: cannot operate on dangling symlink

Das Ziel des Symlinks existiert nicht. Deswegen schlägt das Kommando fehl.

 

Du kannst dir den symlink so ausgeben lassen:

ls -l <Pfad>

 

Fazit: Symlink löschen oder korrigieren.

[Revan335]

Vielen Dank! @mgutt

 

Gibt es ne Möglichkeit mehrere symlinks gleichzeitig zu löschen oder zu korrigieren? Statt dies händisch einzeln machen zu müssen.

Quasi sowas wie bei Rekursiver Rechtevergabe.

[derHarry]

Hallo Gemeinde,

 

ich häng mich hier mal an - hab ein ähnliches Problem, allerdings nur mit Dateien/Ordnern im Ordner "/mnt/user/system/docker/btrfs/subvolumes/".

 

Nachdem der Output des Extended Tests exakt 95.249 Zeilen hat, hänge ichs hier nur Auszusgsweise an, die Einträge ändern sich eh nur am Ende

 

The following directories exist with similar names, only differing by the 'case' which will play havoc with Windows / SMB access.  Windows does NOT support folder names only differing by their case and strange results will happen should you attempt to manipulate the folders or files

/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/usr/lib/x86_64-linux-gnu/perl/5.32.1/sys
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/usr/lib/x86_64-linux-gnu/perl/5.32.1/Sys
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/usr/share/perl/5.32.1/pod
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/usr/share/perl/5.32.1/Pod
/mnt/user/system/docker/btrfs/subvolumes/07aaf6038ef07fa8877b6cc9888fc8e62c6d24ab4b5282dc67a7c5b1d0d8625c/usr/lib/x86_64-linux-gnu/perl/5.32.1/sys
/mnt/user/system/docker/btrfs/subvolumes/07aaf6038ef07fa8877b6cc9888fc8e62c6d24ab4b5282dc67a7c5b1d0d8625c/usr/lib/x86_64-linux-gnu/perl/5.32.1/Sys
/mnt/user/system/docker/btrfs/subvolumes/07aaf6038ef07fa8877b6cc9888fc8e62c6d24ab4b5282dc67a7c5b1d0d8625c/usr/share/perl/5.32.1/pod
/mnt/user/system/docker/btrfs/subvolumes/07aaf6038ef07fa8877b6cc9888fc8e62c6d24ab4b5282dc67a7c5b1d0d8625c/usr/share/perl/5.32.1/Pod
etc...

 

The following files / folders may not be accessible to the users allowed via each Share's SMB settings.  This is often caused by wrong permissions being used on new downloads / copies by CouchPotato, Sonarr, and the like:

/mnt/user/system/docker/btrfs/subvolumes/008b38b5a89e899a4bffc5c69ac2a0df48481d6b0f7d6bda433e15ee821c947a/bin/arch   root/root (/)  0
/mnt/user/system/docker/btrfs/subvolumes/008b38b5a89e899a4bffc5c69ac2a0df48481d6b0f7d6bda433e15ee821c947a/bin/ash   root/root (/)  0
/mnt/user/system/docker/btrfs/subvolumes/008b38b5a89e899a4bffc5c69ac2a0df48481d6b0f7d6bda433e15ee821c947a/bin/bbconfig   root/root (/)  0
/mnt/user/system/docker/btrfs/subvolumes/008b38b5a89e899a4bffc5c69ac2a0df48481d6b0f7d6bda433e15ee821c947a/bin/dmesg   root/root (/)  0
/mnt/user/system/docker/btrfs/subvolumes/008b38b5a89e899a4bffc5c69ac2a0df48481d6b0f7d6bda433e15ee821c947a/bin/dnsdomainname   root/root (/)  0
/mnt/user/system/docker/btrfs/subvolumes/008b38b5a89e899a4bffc5c69ac2a0df48481d6b0f7d6bda433e15ee821c947a/bin/dumpkmap   root/root (/)  0
...
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/etc/alternatives/netcat   root/root (/)  0
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/etc/alternatives/open   root/root (/)  0
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/etc/alternatives/pager.1.gz   root/root (/)  0
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/etc/alternatives/phar   root/root (/)  0
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/etc/alternatives/phar.phar   root/root (/)  0
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/etc/alternatives/php   root/root (/)  0
etc...

The following files / folders contain illegal characters in its name, which is going to confuse / cause issues with Windows / MAC systems:

/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/var/lib/dpkg/info/bind9-libs:amd64.list
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/var/lib/dpkg/info/bind9-libs:amd64.md5sums
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/var/lib/dpkg/info/bind9-libs:amd64.shlibs
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/var/lib/dpkg/info/bind9-libs:amd64.triggers
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/var/lib/dpkg/info/gcc-10-base:amd64.list
/mnt/user/system/docker/btrfs/subvolumes/01935633bc8e19730019335f2d2b1aa962053764140eaa198b83cf9886444063/var/lib/dpkg/info/gcc-10-base:amd64.md5sums
etc... 

 

Generell mach ich im Share "system" bewusst gar nix - ich habe daher Fragen 🙂

a) Weiss jemand, warum hier manche Verzeichnisse doppelt angelegt werden, mit dem einzigen Unterschied der Gross-/Kleinschreibung? 

b) Bzgl. der Rechte: Ich habe eigentlich das "Docker Safe New Perms" Script laufen gelassen, das scheint hier nicht so richtig geholfen zu haben..

c) Auch die unerlaubten Zeichen in den Dateinamen sind ja offensichtlich nicht von mir so angelegt worden, sondern automatisch - Wieso ist das einerseits erlaubt und andererseits, warum passiert das überhaupt?

d) Sind die Fehlermeldungen für diese Verzeichnisse überhaupt relevant, oder sollte ich /system/docker einfach aus dem Extended Test exkludieren?

e) warum gibts für "system" überhaupt einen Standardshare, da drin pfuscht man doch normalerweise eher nicht herum, oder?

 

Bonusfrage: der Share "system" liegt auf einem Raid1 SSD Cachepool - kann die Dopplung etwas damit zu tun haben?

Settings:

 

Vielen Dank im Voraus!

 

 

Edited December 3, 2022 by derHarry

[DataCollector]

Hallo.

 

Ich verstehe zwar, daß die Ausgaben des Extended Test beunruhigen, aber ansonten...

 

#Bezogen auf den Block, der wie folgt überschrieben ist:
"The following directories exist with similar names, only differing by the 'case' which will play havoc with Windows / SMB access.  Windows does NOT support folder names only differing by their case and strange results will happen should you attempt to manipulate the folders or files"

 

Das sind Dockerinterne Verzeichnisse. Was soll man da mit einem Windows/Mac System drauf machen?

Ich verstehe nicht: Wenn Docker intern (auf Linuxbasis) damit klar kommt, warum ist es relevant, dass ein von außen vielleicht mal draufschauendes System mit Windows oder Mac damit nicht klar kommt? Wieso sollte ein Windows-/Macsystem da drauf schauen?

 

# Bezogen auf den Block, der wie folgt überschrieben ist:
"The following files / folders may not be accessible to the users allowed via each Share's SMB settings.  This is often caused by wrong permissions being used on new downloads / copies by CouchPotato, Sonarr, and the like:"

 

Warum sollten überhaupt normale User in den Docker internen Verzeichnissen herumwuseln? Wenn ich Fehler in einem Docker in den dort abgelegten/benutzen Dateien suchen würde, greife ich von unraid aus über den mc oder Krusader darauf zu. DIe sind eigentlich mit weitreichensten Rechten ausgestattet. Warum sollte man diese Dockerdateien/-Verzeichnisse überhaupt per SMB freigeben um dann von außen per Windows/Mac darauf zuzugreifen?

#Bezogen auf den Block, der wie folgt überschrieben ist:
"The following files / folders contain illegal characters in its name, which is going to confuse / cause issues with Windows / MAC systems:"

Solange Du nicht mit Windows/Mac System in dem Docker Verzeichnis herumspielst sollte das ja kein Problem darstellen.
Die Dockercontainer benutzen eben Zeichen, die Windows/Mac evtl. nicht "schmecken" Win und Mac haben da aber auch gar nichts drauf zu suchen.

 

Ich habe bei den gelisteten Verzeichnissen und Dateinamen nichts erkannt, was wirklich per SMB von außen oder vom normal bedienenden User zugänglich sein sollte.

Das sieht mir alles nach Interna von Docker selbst oder den jeweiligen Containern aus.

 

Ich bin in Docker nicht bewandert, deshalb kommt jetzt ein hinkender Autovergleich:

Ich muß nicht im Motorraum jeden Kolbenring mit einem komplett unpassenden Werkzeug korrekt einsetzen können, wenn es das korrekte Werkzeug kostenlos gibt und ich als reiner Fahrer im Motorraum sowieso nichts zu fummeln habe.

 

An die Fachleute, die es besser als ich wissen müßten:

Liege ich so falsch? Muß man per SMB von außen das ganze unraid/docker System per Windows/Mac vollständig erreichen und bearbeiten können?

Wäre die Gefahr einer Verseuchung/Malwarebefall/Fehlbedienung nicht viel zu groß?

[derHarry]

Hi DataCollector,

 

ich seh das im Prinzip ähnlich, dennoch frag ich mich halt, wie es passieren kann, dass die Verzeichnisse doppelt angelegt werden, noch dazu mit unterschiedlicher Schreibweise.

Und warum der Ordner Standardmässig freigegeben ist...

 

LG

[mgutt]

 Die Dateien entstehen nicht von alleine. Das wird der jeweilige Container so installiert haben und wird schon seinen Sinn haben. Würde ich nicht hinterfragen.

 

On 12/3/2022 at 12:48 PM, derHarry said:

e) warum gibts für "system" überhaupt einen Standardshare, da drin pfuscht man doch normalerweise eher nicht herum, oder?

Jeder Root-Ordner, egal auf welchem Pool oder Disk, ist automatisch ein Share. Deine Aufgabe wäre es nur diesen nicht über SMB zu teilen und soweit ich weiß ist das auch standardmäßig nicht so 

[derHarry]

On 12/5/2022 at 10:37 AM, mgutt said:

 Die Dateien entstehen nicht von alleine. Das wird der jeweilige Container so installiert haben und wird schon seinen Sinn haben. Würde ich nicht hinterfragen.

all clear, dann solls mich auch nicht weiter beschäftigen....

 

On 12/5/2022 at 10:37 AM, mgutt said:

Jeder Root-Ordner, egal auf welchem Pool oder Disk, ist automatisch ein Share. Deine Aufgabe wäre es nur diesen nicht über SMB zu teilen und soweit ich weiß ist das auch standardmäßig nicht so 

Nur um hier Missverständnissen vorzubeugen: Ich habe den "System" Share natürlich nicht freigegeben - weder über SMB noch über NFS noch sonst wie. Ich seh da auch keinen Sinn drin, ich würde ja auch unter Windows nicht \system32 freigeben, wozu auch? 

Ich frage mich lediglich, warum es hier zu "Fehlern" kommt bzw. ob ich diese getrost ignorieren kann bzw. den "Share" dann aus dem extended Test exkludieren kann... 

thx

[mgutt]

9 minutes ago, derHarry said:

Ich frage mich lediglich, warum es hier zu "Fehlern" kommt

Also ich habe diese Meldung nicht. Und ich nutze docker ja auch als Verzeichnis. Sicher, dass du den Ordner nicht irgendwie doch als Share aktiv hast? NFS? Ansonsten frag mal im entsprechenden Thread vom Plugin warum das überhaupt gescannt wird.