ahoi -
Ein gutes Jahr lang konnte ich per NFS auf meine TS 109 pro II zugreifen.
Seid Samstag aber kommt beim mount-versuch:
mount.nfs: mount(2): Permission deniedmount.nfs: access denied by server while mounting 192.168.1.5:/share/HDA_DATA/Qmultimedia
Einen tollen Workaround hatte ich am Sonntag gefunden: ich gehe per ssh auf das NAS und bitte es um
...und siehe da: mounten geht wieder bis zum nächsten Reboot vom NAS.
Ich musste also beim Startup vom NAS jedesmal die nfs-utils neu installieren - eine Traumlösung war das nicht.
Nach dem reinstall der nfs-utils sagt exportfs auf dem NAS:
/share/HDA_DATA/Qmultimedia 192.168.1.*/share/HDA_DATA/Qdownload 192.168.1.*/share/HDA_DATA/Public 192.168.1.*
aaaber nach dem Neustart vom NAS sagt sein exportfs
und leider: wird dieses etab file bei jedem Neustart neu generiert - es nützt als nix, wenn ich das "mapping=identity" von Hand rauslösche.
--
Achja: was geschah am Samstag? Ich kaufte einen neuen Router und baute ihn ein. Dabei gab es fuer einige Minuten den illegalen Zustand, dass der Router dem NAS die Adresse 192.168.1xy.22 geben wollte, aber das NAS eine feste IP von 192.168.1.5 haben wollte. Seitdem: ist irgend ein Wurm drin.
--
Am Sonntag habe ich dem NAS die neueste Firmware 3.3.0 spendiert (vorher war 3.1.0) - brachte aber keine Linderung.
---
Seid Montag: klappt auch der reinstal nfs-utils trick nicht mehr - die permission bleibt denied.
Habe ein auf Empfehlung von http://forum.qnap.com/viewtopic.php?f=35&t=32147 ein Downgrade auf Firmware 3.2.0 eingespielt, brachte aber nix.
achja: exportfs -v auf dem NAS liefert
/share/HDA_DATA/Qmultimedia
192.168.1.*(rw,async,wdelay,no_root_squash,anonuid=65534,anongid=65534)
/share/HDA_DATA/Qdownload
192.168.1.*(rw,async,wdelay,no_root_squash,anonuid=65534,anongid=65534)
/share/HDA_DATA/Public
192.168.1.*(ro,async,wdelay,no_root_squash,anonuid=65534,anongid=65534)
Die uid 65534 gehört typischerweise zum user "nobody". Den gibt es allerdings nicht auf meinem NAS. Ist das das Problem?
mit ratloser Verneigung -
- felix