[1] MLD-5.x / General / [MLD5.5 testing/unstable]: Bekomme NFS Share fuer Daten nicht ans laufen
 

Offline RaHe67

  • Newbie
  • *
  • Posts: 37
    • View Profile
Mit vielen Versuchen habe ich es geschafft, fuer meinen virtualisierten MLD Server den NFS Share bekannt zu machen. Allerdings habe ich jetzt ein Problem mit den Zugriffsrechten.

Im Log des VDRs steht folgendes:
Code: [Select]
VDR exits at So Dez 11 17:20:10 CET 2022
vdr: can't access video directory /data/tv

Wenn ich mit putty und root Rechten nachschaue:
Code: [Select]
> ls /data -la
drwxrwsrwx    3 777      100           4096 Dec 11 16:16 .
drwxrwxr-x    1 root     root           142 Dec 11 14:40 ..
drwxrwsr-x    2 777      100           4096 Dec 11 16:16 tv
> ls /data/tv -la
drwxrwsr-x    2 777      100           4096 Dec 11 16:16 .
drwxrwsrwx    3 777      100           4096 Dec 11 16:16 ..

Ordner kann ich auch selbst anlegen, die bekommen dann aber den 'nobody' owner
Code: [Select]
MLD-SERVER> mkdir blubb
MLD-SERVER> ls -la
drwxrwsrwx    4 777      100           4096 Dec 11 18:01 .
drwxrwxr-x    1 root     root           146 Dec 11 17:56 ..
drwxrwsr-x    2 nobody   100           4096 Dec 11 18:01 blubb
drwxrwsr-x    2 777      100           4096 Dec 11 16:16 tv

Die fstab sieht so aus:
Code: [Select]
proc        /proc           proc      defaults            0 0
sys         /sys            sysfs     defaults            0 0
run         /run            tmpfs     defaults            0 0
tmp         /tmp            tmpfs     defaults            0 0
dev         /dev            devtmpfs  defaults            0 0
devpts      /dev/pts        devpts    mode=0620,gid=5     0 0
/dev/dvd    /media/dvd      auto      ro,noauto           0 0
/dev/cdrom  /media/cdrom    auto      ro,noauto           0 0
UUID=41a2a554-1944-4596-ac15-73e0e8dbe5e3  /  auto  defaults  0 1
UUID=e6dfe2d2-d392-42f6-b33a-6233320e8fbf  /mnt/vda3  auto  defaults  0 2
/mnt/vda3/.cache  /var/cache  none  bind  0 0
192.168.2.3:/export/VdrData  /mnt/192.168.2.3__export_VdrData  nfs  bg  0 0
/mnt/192.168.2.3__export_VdrData  /data  mergerfs  defaults,category.create=mfs,direct_io,use_ino  0 0

Den Ordner Tv hat der vdr selbst angelegt, da ich zusätzlich ja auch Zugriff (als root) von MLD aus habe gehe ich davon aus, dass der Share prinzipiell funktioniert.
Was fehlt mir noch, oder wo habe ich meinen Denkfehler?

Hat jemand eine Idee was ich noch prüfen kann?

Ralf
HP ProLiant MicroServer Gen8 G1610T 10 GB + OMV6
MLD Server 5.5 Testing/Unstable on KVM (Sat-IP)

MLD Client 5.4 Stable Zotac IonItx P 4GB RAM
MLD Client 5.4. Stable NUC6CAYH 8GB RAM

DD Octopus NET V2 Max M4

Online clausmuus

  • Administrator
  • Expert Member
  • ********
  • Posts: 20122
    • View Profile
    • ClausMuus.de
Hast du mal mit dem mount Befehl nachgeschaut, ob der nfs Mount und der mergerfs Mount erfolgreich durchgeführt wurden?
MLD 5.5 - Raspberry PI - 7" Touch TFT - Squeeze Play
MLD 5.5 - lirc yaUsbIR - OctopusNet - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - 12TB HDD - Lian Li PC-C37B - Samsung LE40A559

Offline herb01

  • Member
  • **
  • Posts: 84
    • View Profile
Hi Ralf,

da der VDR unter MLD mit root-Rechten läuft, würde ich prüfen, ob die Option "no_root_squash" in "/etc/exports" bei Dir existiert. Wenn nicht, dann könnte dies das Problem sein.

Viele Grüße
Herbert
« Last Edit: December 12, 2022, 07:42:40 by herb01 »

Offline RaHe67

  • Newbie
  • *
  • Posts: 37
    • View Profile
Hast du mal mit dem mount Befehl nachgeschaut, ob der nfs Mount und der mergerfs Mount erfolgreich durchgeführt wurden?
Die Mounts sehen so aus:
Code: [Select]
MLD-SERVER> mount
/dev/vda2 on / type btrfs (rw,relatime,noacl,space_cache,subvolid=259,subvol=/@root)
proc on /proc type proc (rw,relatime)
sys on /sys type sysfs (rw,relatime)
tmp on /tmp type tmpfs (rw,relatime)
run on /run type tmpfs (rw,relatime)
dev on /dev type devtmpfs (rw,relatime,size=1007184k,nr_inodes=251796,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
/dev/vda3 on /mnt/vda3 type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/vda3 on /var/cache type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
192.168.2.3:/export/VdrData on /mnt/192.168.2.3__export_VdrData type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.3,mountvers=3,mountproto=tcp,local_lock=none,addr=192.168.2.3)
/mnt/192.168.2.3__export_VdrData on /data type fuse.mergerfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)

Unbedarft wie ich bin - für mich sieht das gut aus oder?

würde ich prüfen, ob die Option "no_root_squash" in "/etc/exports" bei Dir existiert

Damit wird es nicht wirklich besser. Die Exports auf der NAS Seite:
Code: [Select]
/export/VdrData 192.168.2.4(fsid=c0b5a160-2fe4-4956-883c-2147ed7a2245,rw,subtree_check,insecure,no_root_squash)

# NFSv4 - pseudo filesystem root
/export 192.168.2.4(ro,fsid=0,root_squash,no_subtree_check,hide)

Hab nochmal den Inhat /data Ordner gelöscht bevor ich gestartet habe ...
Erhalte dann wiederholte segfaults.

VdrLog:
Code: [Select]
egmentation fault
VDR exits at Mo Dez 12 20:18:46 CET 2022
Segmentation fault
VDR exits at Mo Dez 12 20:18:57 CET 2022
Segmentation fault
VDR exits at Mo Dez 12 20:19:08 CET 2022
Segmentation fault
VDR exits at Mo Dez 12 20:19:19 CET 2022
Segmentation fault
VDR exits at Mo Dez 12 20:19:29 CET 2022
Segmentation fault
VDR exits at Mo Dez 12 20:19:40 CET 2022
Segmentation fault
VDR exits at Mo Dez 12 20:19:51 CET 2022

Im SystemLog:
Code: [Select]
Dec 12 20:19:29 MLD user.err vdr: epg2vdr: Info: Calling mysql_library_init()
Dec 12 20:19:29 MLD user.info kernel: [   64.471951] vdr[4767]: segfault at 8 ip 0000563c2d345bc0 sp 00007ffd8acd32f8 error 4 in vdr[563c2d2af000+f4000]
Dec 12 20:19:29 MLD user.info kernel: [   64.471969] Code: 06 00 48 8b 08 e8 90 a4 f6 ff 31 c0 e9 9a fb ff ff 45 0f b6 7e 01 89 04 24 49 83 c6 01 e9 10 fd ff ff 8b 1c 24 e9 4b fe ff ff <48> 8b 4f 08 48 8d 3d 55 25 0d 00 45 31 c0 e9 0d 13 f9 ff 90 66 66
Dec 12 20:19:31 MLD daemon.err nmbd[3806]: [2022/12/12 20:19:31.155953,  0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)

Ralf
HP ProLiant MicroServer Gen8 G1610T 10 GB + OMV6
MLD Server 5.5 Testing/Unstable on KVM (Sat-IP)

MLD Client 5.4 Stable Zotac IonItx P 4GB RAM
MLD Client 5.4. Stable NUC6CAYH 8GB RAM

DD Octopus NET V2 Max M4

Offline RaHe67

  • Newbie
  • *
  • Posts: 37
    • View Profile
Zusatzhinweis:
Habe jetzt nochmal parallel einen MLD5.4 Server (Stable) aufgesetzt als VM.
Der NFS Share funktioniert hier (auf Anhieb besser) als mit MLD5.5.
Zumindest konnte ich vom MLD drauf zugreifen und der VDR stürzt auch nicht ab.

Ich konfiguriere dieses System mal weiter und schaue, ob ich hier weiter komme.

Edit: Aufnahmen funktionieren wie erwartet auf der MLD5.4 VM (im NFS-Share) ohne auffälligkeiten.

Wie kann ich helfen das Problem für MLD5.5 weiter einzugrenzen?
Da ich ja jetzt ausschliessen kann, dass der Share das Problem ist, koennte ich die nächsten Tage (noch einmal!) die MLD5.5 genauso wie die 5.4 aufsetzen - auch wenn ich nicht glaube dass ich dort weiter komme - das Problem scheint grundsätzicher zu sein.
Für heute mache ich jedenfalls erst mal Schluss.

Besten Dank für die Unterstützung soweit ...

Ralf
« Last Edit: December 12, 2022, 22:15:59 by RaHe67 »
HP ProLiant MicroServer Gen8 G1610T 10 GB + OMV6
MLD Server 5.5 Testing/Unstable on KVM (Sat-IP)

MLD Client 5.4 Stable Zotac IonItx P 4GB RAM
MLD Client 5.4. Stable NUC6CAYH 8GB RAM

DD Octopus NET V2 Max M4

Offline rfehr

  • MLD-Developer
  • Expert Member
  • ******
  • Posts: 1462
    • View Profile
Hi Ralf,

hast du bei der MLD 5.5 das nfs-client paket installiert?

Gruß,
  Roland
1x OctopusNet 4x DVB-C
1x Zotac ITX-A Atom 330
1x RPI2 als Client
1x BananaPi
1x Wetekplay
1x MCC 100
2x RPI3
2x RPi4
1x https://www.zotac.com/at/product/mini_pcs/pi335

Offline RaHe67

  • Newbie
  • *
  • Posts: 37
    • View Profile
Hallo Roland,

ja das ist drin. Sporadisch hatte er ja unter /data auch schon den /tv Ordner (kurz vorm segfault) angelegt. Per Putty als root konnte ich problemlos von der MLD Seite in den Share Greifen und Daten anlegen/loeschen.

Ralf
HP ProLiant MicroServer Gen8 G1610T 10 GB + OMV6
MLD Server 5.5 Testing/Unstable on KVM (Sat-IP)

MLD Client 5.4 Stable Zotac IonItx P 4GB RAM
MLD Client 5.4. Stable NUC6CAYH 8GB RAM

DD Octopus NET V2 Max M4

Offline rfehr

  • MLD-Developer
  • Expert Member
  • ******
  • Posts: 1462
    • View Profile
ein Debug-Log wäre mal gut
1x OctopusNet 4x DVB-C
1x Zotac ITX-A Atom 330
1x RPI2 als Client
1x BananaPi
1x Wetekplay
1x MCC 100
2x RPI3
2x RPi4
1x https://www.zotac.com/at/product/mini_pcs/pi335

Online clausmuus

  • Administrator
  • Expert Member
  • ********
  • Posts: 20122
    • View Profile
    • ClausMuus.de
Es ist wichtig, das der /data Ordner leer ist, wenn der mergerfs Mount noch nicht durchgeführt wurde. Ich bin nicht ganz sicher wie sich das System andernfalls verhält, aber richtig funktionieren tut's mit gefülltem Ordner jedenfalls nicht.
MLD 5.5 - Raspberry PI - 7" Touch TFT - Squeeze Play
MLD 5.5 - lirc yaUsbIR - OctopusNet - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - 12TB HDD - Lian Li PC-C37B - Samsung LE40A559

Online clausmuus

  • Administrator
  • Expert Member
  • ********
  • Posts: 20122
    • View Profile
    • ClausMuus.de
Mir fällt gerade noch auf, dass bei der Gruppe das Sticky Bit gesetzt ist. Ich weiß grad nicht auswendig was das bewirkt: drwxrwSr-x
Hast Du auch mal getestet, ob Du im Ordner /data/tv Dateien anlegen kannst? Also nicht nur unter /data
MLD 5.5 - Raspberry PI - 7" Touch TFT - Squeeze Play
MLD 5.5 - lirc yaUsbIR - OctopusNet - XFX GeForce 9300 mit Intel E3200 - 2GB RAM - 12TB HDD - Lian Li PC-C37B - Samsung LE40A559

Offline RaHe67

  • Newbie
  • *
  • Posts: 37
    • View Profile
Hab mal ein Debug-Log mit dem Crash angehängt.

Allerdings habe ich diesen Crash auf einmal nicht mehr nachvollziehbar hinbekommen. Ich vermute auf dem MLD System war auf dem MLD System aus vorhergehenden Versuchen ein Order /data angelegt, den ich nun geloescht habe. Könnte es sein dass dieser mit dem NFS Mount der auch dorthin mapped in Konflikt geraten ist?

Das Sticky Bit hatte ich bereits in meinen Versuchen vorher geloescht, sowie alle Unterordner.

Der Zugriff vom (nun laufenden Vdr) auf den data NFS Mount ist jetzt erstmal gegeben - soweit sieht es wohl gut aus.
Für weitere Aussagen/Tests wird es mir gerade wieder mal zu spät - ich bleibe aber die Nächsten Tage am Thema dran. Melde mich auf jeden Fall noch ...

Besten Dank soweit für die Hinweise

Ralf

HP ProLiant MicroServer Gen8 G1610T 10 GB + OMV6
MLD Server 5.5 Testing/Unstable on KVM (Sat-IP)

MLD Client 5.4 Stable Zotac IonItx P 4GB RAM
MLD Client 5.4. Stable NUC6CAYH 8GB RAM

DD Octopus NET V2 Max M4

Offline RaHe67

  • Newbie
  • *
  • Posts: 37
    • View Profile
Der NFS Share scheint soweit erstmal zu laufen. Mein Problem war wohl eine Überlagerung von falscher NFS Share Konfiguration ('no_root_squash' fehlte, Unwissenheit über die korrekten Einträge in der fstab, falsche Benutzung des MLD Web-IF zum NFS Share Mappen und dazu noch störende Daten in /data bzw. falsch angelegt :-)

Der beschriebene VDR Segfault kam dann noch zusätzlich dazu und hat verhindert, dass ich das Problem oben lösen konnte.
Dafür habe ich ein eigenes Thema aufgemacht - da dieser nicht mit dem Share zusammenhaengt.

https://www.minidvblinux.de/forum/index.php/topic,10451.msg83190.html#new

Ralf
HP ProLiant MicroServer Gen8 G1610T 10 GB + OMV6
MLD Server 5.5 Testing/Unstable on KVM (Sat-IP)

MLD Client 5.4 Stable Zotac IonItx P 4GB RAM
MLD Client 5.4. Stable NUC6CAYH 8GB RAM

DD Octopus NET V2 Max M4

[1] MLD-5.x / General / [MLD5.5 testing/unstable]: Bekomme NFS Share fuer Daten nicht ans laufen
 



Users Online Users Online

0 Members and 1 Guest are viewing this topic.