Fix Common Problems Extended Test Meldungen

[Revan335]

Hallo,

 

habe mal den Extended Test bei Fix Common Problems gestartet und Meldungen wie diese bekommen und frage mich, was diese mir sagen sollen und wie ich diese beheben kann.

 

Scheinbar alles Dateien die ich mit Krusader von den USB Platten und Sticks übertragen habe.

 

The following user shares will be excluded from the permissions tests:

/mnt/user/appdata

Processing /mnt/user/Altes NAS
Processing /mnt/user/domains
Processing /mnt/user/isos
Processing /mnt/user/Multimedia
Processing /mnt/user/SHARE
Processing /mnt/user/system
Processing /mnt/user/Test
Processing /mnt/user/Transcode
Processing /mnt/user/.Trash-0

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

Bspw.: Weil es sonst zu viele werden
/mnt/user/Altes NAS/Backup-NAS/USB Backup ohne Acronis/latest/Multimedia/Multimedia/Filme/test
/mnt/user/Altes NAS/Backup-NAS/USB Backup ohne Acronis/latest/Multimedia/Multimedia/Filme/Test

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:

Bspw.: Weil es sonst zu viele werden
/mnt/user/Altes NAS/Backup/aquota.user   root/root (0/0)  0600
/mnt/user/Altes NAS/Backup-NAS/USB Backup ohne Acronis/latest/Download/Antivirus_logs_2018_12_26.zip   root/root (0/0)  0770
/mnt/user/Altes NAS/Backup-NAS-2/USB Backup 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20211209-221501-662/backup/home/username/Downloads/platform-tools/systrace/catapult/third_party/polymer/components/iron-location/demo/index.html   test/ (1000/1000)  0640
/mnt/user/Altes NAS/Backup-NAS-2/USB Backup 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20211224-124501-154/backup/home/username/Bilder/Einkauf/IMG_20210821_203635.jpg   test/ (1000/1000)  0740
/mnt/user/Altes NAS/Backup-NAS-2/USB Backup 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20211224-124501-154/backup/home/username/Downloads/platform-tools/NOTICE.txt   test/ (1000/1000)  0640
/mnt/user/Altes NAS/Backup-NAS-2/USB Backup 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20211224-124501-154/backup/home/username/Downloads/Downloads   root/root (/)  0

 

Vielen Dank!

 

Viele Grüße

 

Revan335

[Squid]

7 minutes ago, Revan335 said:

/mnt/user/Altes NAS/Backup-NAS/USB Backup without Acronis/latest/Multimedia/Multimedia/Filme/test

Without the rest of them it's kind of meaningless, but ultimately the issue is that so far as Windows / SMB is concerned, a file (or directory) named TEST is the exact same file as one named test or one named TeSt.

 

The issue results in that which file actually shows up.  Is it TEST or test or TeSt?

 

In your case, you've got 2 files (or directories) which are effectively identical over SMB.  This may confuse the remote system.

 

The permissions test may not be applicable to you.

 

TBH, I'm debating removing the entire extended tests as pretty much no matter what you do you're always going to have an "issue"   (But the same name / different case is an issue depending upon how you or another app accesses the files / folders)

[DataCollector]

Bezogen auf die Meldung:

"The following directories exist with similar names, only differing by the 'case' which will play havoc with Windows"

Ja, das Problem habe ich auch schon (in abgewandelter Form) beobachtet, wenn ich Dateien in ihrer Groß-/Kleinschreibung auf einem Windowssystem verändert habe und dann den Bestand zwischen Windows und unraid versucht habe abzugleichen (von Windows aus mit dem TotalCommander).

Linux und Windows handhaben die Sache mit der Groß-/Kleinschriebung unterschiedlich, wodurch auf unraid dann zwei Dateien existieren können, die aber beide (fast) gleich heißen.

 

In Deinem Fall sind es wohl eher 2 Verzeichnisse, die eben beide 'test' heißen, nur einmal eben mit einem Großbuchstaben und einmal alles klein.

Wenn Du dann von Windows auf darauf zugreifst, sieht Du nur eine der Dateien.

 

 

Zu der Sache mit den Berechtigungen...

 

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

 

...vermute ich, daß Du auf etwas ähnliches gestoßen bist, was mir schon im Juli auf meinem Testsystem Bauchschmerzen bereitet hat. Da hatte ich mir durch Kopieraktionen mit rsycn Daten aufs unraid geschaufelt und später erst festgestellt, daß ich Zugriffsprobleme habe. Da bin ich dann als Windowsnutzer das erste Mal mit chmod in Berührung gekommen.

 

 

[Revan335]

Dieses bei @DataCollector Thread genannte Docker Tool Safe Perms setzt die Permissions anhand dessen was man in Unraid eingestellt hat für die Shares?

Es sei den man exkludiert diese in Fix Common Problems, was bei Appdata/CA Backup Destination? automatisch/immer der Fall ist?

Also wenn man bspw. Gäste keinen Zugriff gibt oder nur bestimmten Usern wird dies über das Tool gemacht? Oder ist es dann free for Everyone und man muss die Rechte erneut für die Shares setzen?

[mgutt]

Der setzt alles auf nobody also Standard. Du sprichst von SMB. Das hat nichts damit zu tun.

[Revan335]

Über Localhost am Server selbst funktioniert der Docker NewPerm Run und das Webinterface ist auch um einiges schneller. Über das Webinterface am bspw. Tablet nicht, da er entweder nicht weiterläuft oder aus anderen Gründen es nicht abschließen kann.

 

Habe nun Dateien/Ordner drin ohne Meldung am Ende wie root/root (/)  0. Den Rest den ich überfliegen konnte, ist mit root/root (/)  0 gekennzeichnet.

 

Gemacht hat er also einiges. Weil die anderen verschwunden sind und es auch weniger geworden sind.

 

Das mit Test, test oder Leerzeichen im Namen an Anfang und Ende, kann man ja noch fixen, wenn die Rechte wieder gerade sind.

 

Was könnte man noch machen um die Rechte zu fixen ohne sie per Script zu "zerstören" weil es die falschen gesetzt hat?

 

Poste später noch Auszüge aus dem neuen Extended Log. Dann seht ihr die Beispiele mit root/root (/)  0 und ohne.

Edited April 13, 2022 by Revan335

[DataCollector]

3 hours ago, Revan335 said:

Was könnte man noch machen um die Rechte zu fixen ohne sie per Script zu "zerstören" weil es die falschen gesetzt hat?

Ich habe Rechte mit dem MC auch anpassen können.

Ist aber eben Handarbeit.

 

[Revan335]

/mnt/user/Altes NAS/Backup/Vu+ Solo2 HDD/Aufs NAS 1/.@__thumb/a10020141003 1958 - kabel eins HD - Bodyguard.ts   root/root (/)  0
/mnt/user/Altes NAS/Backup-NAS-2/USB Backup 2/latest/Backup_Daten/Backup_Linux/BIT/backintime/PCname/username/1/20210131-214103-698/backup/home//Bilder/Auswahl_2015-05-31-13:27:26.jpg

Hier zwei Beispiele.

 

3 hours ago, DataCollector said:

Ich habe Rechte mit dem MC auch anpassen können.

Ist aber eben Handarbeit.

Muss ich das dann so einstellen wie auf den Bildern? Gibt es dort auch nen Rekursiv Button, da es scheinbar nur einzelne Ordner und manche Dateien dort betrifft?

[mgutt]

Das Linux Kommando "find" kann übrigens auch Dateien rekursiv an Hand der Rechte finden:

 

find /mnt/user -type f -perm 0000 -user root -group root

 

Ist man mit dem Suchergebnis zufrieden, kann man es wie folgt erweitern um die Rechte zu korrigieren:

 

find /mnt/user -type f -perm 0000 -user root -group root -exec chmod -v 666 {} \; -exec chown -v nobody:users {} \;

 

In dem Fall also in 666 und der neue Inhaber wird nobody aus der Gruppe users.

[DataCollector]

12 hours ago, Revan335 said:

Muss ich das dann so einstellen wie auf den Bildern? Gibt es dort auch nen Rekursiv Button, da es scheinbar nur einzelne Ordner und manche Dateien dort betrifft?

Ich hatte die Bilder nur angehängt, weil ich diese Option im MC auf Anhieb nicht gefunden hatte. Sie sind also nur als Wegweiser gedacht.

Welche Optionen Du für Deinen Anwendungszweck wählen willst, bleibt Dir überlassen.

Kannst ja erst einmal mit einer Datei anfangen und prüfen, mit welchen Einstellungen Du das gewünschte Ergebnis erreichst.

[Revan335]

On 4/14/2022 at 7:29 AM, mgutt said:

Das Linux Kommando "find" kann übrigens auch Dateien rekursiv an Hand der Rechte finden:

 

find /mnt/user -type f -perm 0000 -user root -group root

 

Ist man mit dem Suchergebnis zufrieden, kann man es wie folgt erweitern um die Rechte zu korrigieren:

 

find /mnt/user -type f -perm 0000 -user root -group root -exec chmod -v 666 {} \; -exec chown -v nobody:users {} \;

 

In dem Fall also in 666 und der neue Inhaber wird nobody aus der Gruppe users.

Leider ist das Ergebnis bei mir gar nichts.

 

Auch wenn ich explixit einen Ordner auswähle wo laut ExtendedLog was sein sollte.

 

Muss ich den Befehl vielleicht noch anpassen?

 

/mnt/user/Altes NAS/Backup/Vu+ Solo2 HDD/Aufs NAS 10/.@__thumb/adefault20161206 2210 - ZDF HD - Die Anstalt.ts   root/root (/)  0

[mgutt]

Ermittel bitte mal die chmod Zahl der Datei:

stat -c %a <datei>

 

Vielleicht probier auch mal -perm 0 beim find Kommando.

[Revan335]

5 minutes ago, mgutt said:

Ermittel bitte mal die chmod Zahl der Datei:

stat -c %a <datei>

 

Vielleicht probier auch mal -perm 0 beim find Kommando.

:~# find /mnt/user/Altes\ NAS/Backup/Vu+\ Solo2\ HDD/Aufs\ NAS\ 10/ -type f -perm 0 -user root -group
:~# stat -c %a /mnt/user/Altes\ NAS/Backup/Vu+\ Solo2\ HDD/Aufs\ NAS\ 10/20161206\ 2210\ -\ ZDF\ HD\ -\ Die\ Anstalt.ts
666
:~# 

Ergebnis 666 und nur mit 0, möchte er leider auch nicht.

[mgutt]

Dann hat die Datei auch 666 und nicht 0. Dann nutz beim find Kommando 666.

[Revan335]

Leider bringt er auch dort kein Ergebnis.

 

Wenn ich User und Group aber weglasse und nur -perm 666 schreibe, gibt er was aus.

[Revan335]

Mit stat ohne Parameter zeigt er bei Access bei einer Datei dies an.

 

(0666/-rw-rw-rw-) Uid (99/nobody) Gid (100/users)

 

Ich vermute das dies dann auch für die anderen Dateien im Extended Log gilt.

[mgutt]

Bitte mal nur stat <datei> ausführen. Gehört die Datei überhaupt root:root?

 

EDIT: Ok. Ja dann verstehe ich das root:root von oben zwar nicht, aber ok. nobody:users ist soweit korrekt. Müsste man also nur mit chmod die 666 korrigieren.

 

Denk dran, dass du das überall machen darfst außer bei /mnt/user/appdata und /mnt/user/system/docker bzw wo auch immer dein Docker Verzeichnis liegt.

 

 

[Revan335]

Hab ich jetzt mal gemacht, aber das Extended Log sieht nach neuen Run "unverändert" aus.

Lief über den kompletten Share Altes NAS.

 

Hab nochmal nen Stat gemacht aber weiterhin wie oben.

 

Sehr merkwürdig, als wäre nichts passiert. Egal ob find/chmod oder Docker Permission Skript.

[Revan335]

Andere haben wohl noch andere Berechtigungen:

:~# stat /mnt/user/Altes\ NAS/Backup/Vu+\ Solo2\ HDD/Aufs\ NAS\ 1/.@__thumb/adefault20141226\ 1959\ -\ SAT_1\ HD\ -\ Verblendung.ts
  File: /mnt/user/Altes NAS/Backup/Vu+ Solo2 HDD/Aufs NAS 1/.@__thumb/adefault20141226 1959 - SAT_1 HD - Verblendung.ts -> /share/external/DEV3302_1/Vu+ Solo2 HDD/Aufs NAS 1/.@__thumb/default20141226 1959 - SAT_1 HD - Verblendung.ts
  Size: 109             Blocks: 0          IO Block: 4096   symbolic link
Device: 32h/50d Inode: 649081302191445178  Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (   99/  nobody)   Gid: (  100/   users)
Access: 2022-04-11 19:50:48.918764736 +0200
Modify: 2022-04-11 19:50:48.918764736 +0200
Change: 2022-04-13 23:50:01.100078146 +0200
 Birth: -

 

Aber da findet find nichts. mit ":~# find /mnt/user/Altes\ NAS/Backup/Vu+\ Solo2\ HDD/ -type f -perm 777"

Muss man ggf. noch versteckte (.*) Ordner mit einbeziehen?

 

Edit: ohne den type Filter, wird auch das gefunden.

Edited April 19, 2022 by Revan335

[mgutt]

type -f findet Dateien und type -d Ordner.

[Revan335]

Also müsste ich auch die mit perm 777 mit Change Mod zu 666/nobody:users ändern ohne den Typ Filter?

 

Aus irgendeinem Grund scheint das Beispiel oben auch ein Symlink zu sein mit dem chmod nicht arbeiten kann.

"chmod: cannot operate on dangling symlink"

Edited April 19, 2022 by Revan335

[Revan335]

Bzw. ohne Filter wie Typ, Perm, User/Group müsste ich doch direkt alles erschlagen und es müsste dann alles auf 666/nobody:users sein, sofern chmod bei allen funktioniert hat?

[mgutt]

Ordner erhalten in Unraid normalerweise 777. 666 ist nur für Dateien.

[Revan335]

3 minutes ago, mgutt said:

Ordner erhalten in Unraid normalerweise 777. 666 ist nur für Dateien.

Dann müsste es vermutlich so aussehen wenn man beides abdecken will?

 

Dateien:

find /mnt/user/Altes\ NAS/ -type f -exec chmod -v 666 {} \; -exec chown -v nobody:users {} \;

 

Ordner:

find /mnt/user/Altes\ NAS/ -type d -exec chmod -v 777 {} \; -exec chown -v nobody:users {} \;

[mgutt]

6 hours ago, Revan335 said:

Dann müsste es vermutlich so aussehen wenn man beides abdecken will?

Ja, aber wenn du sowieso alle Dateien abarbeiten willst, kannst du auch Tools > Docker Safe Perms nehmen. Ich ging davon aus, dass du von Hand ausgewählte Dateien korrigieren wolltest. Sorry ^^