MLD-5.x > General
[MLD5.5 testing/unstable]: Bekomme NFS Share fuer Daten nicht ans laufen
RaHe67:
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: ---VDR exits at So Dez 11 17:20:10 CET 2022
vdr: can't access video directory /data/tv
--- End code ---
Wenn ich mit putty und root Rechten nachschaue:
--- Code: ---> 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 ..
--- End code ---
Ordner kann ich auch selbst anlegen, die bekommen dann aber den 'nobody' owner
--- Code: ---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
--- End code ---
Die fstab sieht so aus:
--- Code: ---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
--- End code ---
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
clausmuus:
Hast du mal mit dem mount Befehl nachgeschaut, ob der nfs Mount und der mergerfs Mount erfolgreich durchgeführt wurden?
herb01:
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
RaHe67:
--- Quote from: clausmuus on December 12, 2022, 00:57:15 ---Hast du mal mit dem mount Befehl nachgeschaut, ob der nfs Mount und der mergerfs Mount erfolgreich durchgeführt wurden?
--- End quote ---
Die Mounts sehen so aus:
--- Code: ---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)
--- End code ---
Unbedarft wie ich bin - für mich sieht das gut aus oder?
--- Quote from: herb01 on December 12, 2022, 07:12:13 --- würde ich prüfen, ob die Option "no_root_squash" in "/etc/exports" bei Dir existiert
--- End quote ---
Damit wird es nicht wirklich besser. Die Exports auf der NAS Seite:
--- Code: ---/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)
--- End code ---
Hab nochmal den Inhat /data Ordner gelöscht bevor ich gestartet habe ...
Erhalte dann wiederholte segfaults.
VdrLog:
--- Code: ---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
--- End code ---
Im SystemLog:
--- Code: ---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)
--- End code ---
Ralf
RaHe67:
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
Navigation
[0] Message Index
[#] Next page
Go to full version