[SOLVED] nfs-common [1:1.3.4-1]

[jure]

Hallo,

beim du heute Morgen wurde nfs-common [1:1.3.4-1] installiert. Danach funktionierte bei mir der mount von nfs Verzeichnissen (NAS) nicht mehr und z.B. dolphin verhielt sich seehr träge, ebenso fehlte die kpl. untere "Fensterleiste" für ca 30sec. Alles was irgendwie auf die nfs mounts wartete wurde ausgebremst/hing .

Nach einem downgrade auf nfs-common 1:1.2.8-9.2 (testing) funzt alles wieder.

[hsp]

systemctl enable rpc-statd.service
systemctl start rpc-statd.service

[jure]

systemctl enable rpc-statd.service
systemctl start rpc-statd.service

Danke !

damit läuft es auch mit aktuellen Version von nfs-common [1:1.3.4-1] - aaber der Dienst "rpc-statd.service" ist nach einem reboot nicht automatisch aktiv.
Ich dachte, dass wenn er enabled wurde, er beim Neustart automatisch startet.

[hsp]

Du hast Recht, es gibt noch ein Fehler in den neuen nfs-paketen. Schlechte Qualität kann ich nur sagen das Packaging. Der Postinstallscript schaltet rpc-statd nicht ein wie oben schon erwähnt, es ist auch noch ein Fehler in der Pfadangabe bei ExecStart im nfs-config.service.  Danach sollte alles gut sein, wenn nicht hast du noch ein anderes Problem.

Code: [Select]

holgi@hsp1~ $ cat /lib/systemd/system/nfs-config.service
[Unit]
Description=Preprocess NFS configuration
After=local-fs.target
DefaultDependencies=no

[Service]
Type=oneshot
# This service needs to run any time any nfs service
# is started, so changes to local config files get
# incorporated.  Having "RemainAfterExit=no" (the default)
# ensures this happens.
RemainAfterExit=no
# ExecStart=/usr/libexec/nfs-utils/nfs-utils_env.sh
ExecStart=/usr/lib/systemd/scripts/nfs-utils_env.sh

evtl. noch ein systemctl enable nfs-config.service abschicken


...

[jure]

 rpc-statd.service startet weiterhin nicht automatisch, lässt sich aber von Hand aktivieren, woraufhin NFS funktioniert.

Der Pfad war hier auch falsch (angepasst), aber ein "systemctl enable nfs-config.service" bringt nur

Code: [Select]

systemctl enable nfs-config.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.

[hsp]

Ich kann dir die Lösung sagen warum es nicht funktioniert. Die nfs-pakete sind völlig crazy, ich hab jetzt auch ein downgrade nach testing gemacht. Die Lösung ist völlig bekloppt, das ganze funktioniert nicht weil der nfs-kernel-server nicht installiert ist. Warum man neuerdings die Serverkomponente braucht wenn der Client mounten möchte ist mir schleierhaft. Probier es aus und installiere den Server und du wirst feststellen das plötzlich alles funktioniert. Völlig verbugt das Zeugs, es wird exportfs in systemdfiles vom client benutzt obwohl exportfs im Serverpaket ist. Ist schon sehr seltsam.

...

[jure]

jo das ist etwas wirrig

aaber ich habe mir noch mal die term. logs angesehen, da wurde der vorhandene nfs-kernel-server  [1:1.3.4-1] beim downgrade auf nfs-common [1:1.2.8-9.2] (s.o.) natürlich entfernt. Wurde aber beim (wieder-)upgrade auf nfs-common [1:1.3.4-1] nicht automatisch mit installiert. Habe ich nachinstalliert und scheint wieder normal zu funzen....

Code: [Select]

apt policy nfs-*
nfs-kernel-server:
  Installiert:           1:1.3.4-1
  Installationskandidat: 1:1.3.4-1
  Versionstabelle:
 *** 1:1.3.4-1 500
        500 http://httpredir.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
nfs-client:
  Installiert:           (keine)
  Installationskandidat: (keine)
  Versionstabelle:
nfs-server:
  Installiert:           (keine)
  Installationskandidat: (keine)
  Versionstabelle:
nfs-common:
  Installiert:           1:1.3.4-1
  Installationskandidat: 1:1.3.4-1
  Versionstabelle:
 *** 1:1.3.4-1 500
        500 http://httpredir.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
edit: unnötige quotes entfernt und ergänzt

[hsp]

jure du kannst jetzt upgraden, es sind gefixte Pakete im Repo. Es funktioniert jetzt alles wie es soll (hoffentlich) :-)
Ich hab erst mal keine Probleme mehr.

...

[oduffo]

Ich muss diesen Thread doch noch mal wiederbeleben, da ich das gleiche Problem habe.

Ich habe das neue Release (patience - kde) installiert und eingerichtet. Bisher konnte auf meinen Synology-NAS per nfs zugreifen  Mit der neuen Installation klappt das nicht mehr.


Das Release kommt mit nfs-common 1.3.4-2. Analog zu den Aussagen weiter oben habe ich zusätzlich auch nfs-kernel-server 1.3.4-2 installiert. Das hat auch nichts gebracht.
Einzige - mir bisher bekannte - Lösung: Downgrade von nfs-common auf 1.2.8-9.2 (ist in stable). Damit läuft alles einwandfrei wie zuvor. nfs-kernel-server wird nicht benötigt.


Da ich bisher weder hier im Forum noch im IRC von ähnlichen Problemen gehört habe, will ich nicht ausschließen, dass das Problem in meiner Konfiguration liegt, obwohl mir das bei einer Neuinstallation unwahrscheinlich erscheint.
Ich füge mal den entsprechenden Eintrag aus /etc/fstab bei, mit dem bisher und jetzt nach dem downgrade alles funktioniert

Code: [Select]

ganymed:/volume1/datu /datuNAS  nfs  noauto,x-systemd.automount,defaults  0 0

Für zusätzliche Informationen bin ich im eigenen Interesse natürlich bereit.


Gruß
oduffo

[devil]

Ich hab keine Antwort für dich, höchstens eine Alternative. Mein NAS wird mit autofs ohne Probleme eingebunden. Bei uns im Wiki steht eine grundlegende Config.

[hsp]

Wie ich oben schon geschreibselt habe, die gefixten Pakete rennen ohne Probleme.
Ich hab keine Sorgen mehr mit nfs.

...