# [closed] jpg-Import in digikam scheitert....???

## uhai

Hallo zusammen,

ich habe die vergangenen Jahre jetzt meine Fotos  mit Digikam importiert, jpg wird beim importieren zu png konvertiert. Seit Ende Dezember klappt das aber nicht mehr. Digikam zeigt zwar die png-Bilder als Symbol an, die Vollbildansicht scheitert aber mit dem Fehler "Bild kann nicht geladen werden". Raw-Files von Olympus oder Nikon werden importiert.

Wenn ich mir die Verzeichnisse auf dem NAS mit dem Dateimanager ansehe, sind die sidecar-Files (*.xmp) da, die PNG-Dateien fehlen aber manchmal komplett. Manchmal sind die PNGs auch vorhanden, digikam kann sie aber nicht in der Vollansicht öffnen. PhotoQt kann die Dateien auch nicht anzeigen und beschwert sich "file not found". Bei den RAWs in diesem Verzeichnissen mit PNGs scheitert digikam in der Vollansciht "Datei kann nicht geladen werden". PhotoQt bringt ebenfalls einen Fehler von Libraw "input output error".

Öffne ich die Dateien direkt auf Der NAS - Dateimanager der NAS -> öffnen - dann werden die PNGs angezeigt. Die NAS bediene ich über die WEbschnittstelle im Firefox.

Ich vermute, dass die nfs-Verbindung auf die NAS nicht richtig arbeitet. Die Vorschaubilder holt digikam ja aus der Datenbank, die Vollansicht versucht digikam vermutlich über die nfs-Verbindung zu holen. In der Konsole sieht die Ausgabe von digikam sehr danach aus:

```
digikam.metaengine: Cannot load metadata using Exiv2   (Error # 9 :  /home/uhai/NAS/Fotos/2019/2019-11-22/2019-11-22_18-19-15.PNG: Die Datenquelle konnte nicht geöffnet werden: Eingabe-/Ausgabefehler (errno = 5)
```

Solche Fehler tauchen laufend auf. Die NAS-Verzeichnisse werden mit user:group nobody:nobody gemountet. userid und groupid sind aber auf beiden Geräten eigentlich seit Jahren gleich...

uhaiLast edited by uhai on Wed Feb 12, 2020 7:20 pm; edited 1 time in total

----------

## mike155

"errno = 5". Das ist EIO "I/O error" - ein ungewöhnlicher Fehler für eine Datei Lese-Operation.

Wenn man mit der Suchmaschine seines Vertrauens sucht nach 

```
linux nfs "errno=5"
```

findet man einige Hinweise auf den Portmapper. Hier könntest Du mal schauen. Bei dem Portmapper gab es in den letzten Jahren mehrere Änderungen und Umstellungen. Vielleicht hat sich bei einem Update auf Deinen Maschinen im Dezember etwas geändert?

----------

## uhai

Danke mike155,

das wird es wohl sein, denn ich habe mit journalctl |grep nfs das hier gefunden:

```
Jan 10 19:19:15 After8 nfsidmap[232378]: nss_getpwnam: name 'uhai@localdomain' does not map into domain 'Adlerhorst.local'

Jan 10 19:19:15 After8 nfsidmap[232379]: libnfsidmap: using domain: Adlerhorst.local

Jan 10 19:19:15 After8 nfsidmap[232379]: libnfsidmap: Realms list: 'ADLERHORST.LOCAL'

Jan 10 19:19:15 After8 nfsidmap[232379]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

Jan 10 19:19:15 After8 nfsidmap[232379]: nss_name_to_gid: name 'everyone@localdomain' does not map into domain 'Adlerhorst.local'
```

Anscheinend ist der Domainname irgendwo falsch gesetzt.... nfs kann doch inzwischen auch FQDN oder? Macht die GRoß- bzw. Kleinschreibung einen Unterschied - vermutlich doch,oder? Woher werden die Domainnamen für die user gezogen?

/edit: Auf dem Server hat der Domain-Eintrag in /etc/idmapd.conf nicht gestimmt... hat aber für die user@domain nichts gebracht. Wo muss ich das suchen??

uhai

----------

## mike155

uhai, ich möchte Dir gerne helfen. NFS ist aber kompliziert. Von daher finde ich es schwierig, gleich gezielte Fragen zu stellen. Na gut. Fangen wir ganz von vorne an. Wir müssen erst einmal sehen, was auf Deinen Maschinen konfiguriert ist.

Bitte poste folgende Daten von dem CLIENT:

Die Ausgabe von

```
mount | grep -i nfs
```

Die Ausgabe von

```
showmount -e <IP-Adresse des Servers>
```

Die Ausgabe von 

```
 grep -v "^#" /etc/idmapd.conf | grep "."
```

Die Ausgabe von:

```
zgrep -E "(Kernel Config|NFS)" /proc/config.gz
```

Die Ausgabe von:

```
ps -fe | egrep "nfs|rpc"
```

Bitte poste folgende Daten von dem Server:

Die Ausgabe von 

```
 grep -v "^#" /etc/idmapd.conf | grep "."
```

Die Datei

```
/etc/exports
```

Die Ausgabe von:

```
zgrep -E "(Kernel Config|NFS)" /proc/config.gz
```

Die Ausgabe von:

```
ps -fe | egrep "nfs|rpc"
```

Falls persönliche Daten erscheinen sollten, kannst und solltest Du sie vor dem Posten aus-X-en.

----------

## uhai

Vielen herzlichen Dank Mike155,

das das kompliziert ist, habe ich bereits festgestellt. Ich habe bisher kein Howto finden können, dass miene Konstellation vollständig abgedeckt hat und für mich verständlich war. Außerdem scheint der Server - eine QNAP-NAS - die Konfigurationsdateien anders zu benennen oder anders abzulegen....

Ok, hier sind die Angaben "wie bestellt":

Zuerst der Client:

```
/home/uhai/ mount | grep -i nfs 

192.168.0.100:/Public1 on /home/uhai/public type nfs4 (rw,relatime,vers=4.1,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.24,local_lock=none,addr=192.168.0.100,_netdev)

192.168.0.100:/homes1/uhai on /home/uhai/NAS type nfs4 (rw,relatime,vers=4.1,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.24,local_lock=none,addr=192.168.0.100,_netdev)

```

```
/home/uhai/ showmount -e 192.168.0.100

Export list for 192.168.0.100:

/uhai        

/homes1      

/homes       

/Web         

/Recordings  

/Public1     

/Public      

/Natan       

/Multimedia  

/Download  
```

/homes und /Public sind von einer alten Konfiguration, die ich als "Fallback" noch vorhalte. Das hatte funktioniert, bis ich die QNAP mit neuen Laufwerken erweitert habe. userid und gid waren auf client und server identisch gewesen. Da die Laufwerke (Raid) bereits vollsind, musste ich neue Laufwerke ergänzen. Sobald ich /homes1 und /Public1 auf dem neuen Raid sauber benutzen kann werden die alten  Freigaben entfernt und diese Verzeichnisse auf der NAS gelöscht.

```

/home/uhai/  grep -v "^#" /etc/idmapd.conf | grep "."

[General]

Domain = Adlerhorst.local

[Mapping]

[Translation]

 

[Static]

[UMICH_SCHEMA]

LDAP_server = ldap-server.local.domain.edu

LDAP_base = dc=local,dc=domain,dc=edu

```

Einen LDAP habe ich nicht mehr, das war mal ein Versuch auf der NAS über LDAP die Zugriffsrechte zu organisieren....

```
 zgrep -E "(Kernel Config|NFS)" /proc/config.gz

gzip: /proc/config.gz: No such file or directory
```

Alternativ die Ausgabe aus .config:

```
/usr/src/linux/ cat ./.config | grep NFS   

CONFIG_KERNFS=y

CONFIG_NFS_FS=y

CONFIG_NFS_V2=y

CONFIG_NFS_V3=y

CONFIG_NFS_V3_ACL=y

CONFIG_NFS_V4=y

CONFIG_NFS_SWAP=y

CONFIG_NFS_V4_1=y

CONFIG_NFS_V4_2=y

CONFIG_PNFS_FILE_LAYOUT=y

CONFIG_PNFS_BLOCK=y

CONFIG_PNFS_FLEXFILE_LAYOUT=m

CONFIG_NFS_V4_1_IMPLEMENTATION_ID_DOMAIN="kernel.org"

CONFIG_NFS_V4_1_MIGRATION=y

CONFIG_NFS_V4_SECURITY_LABEL=y

CONFIG_ROOT_NFS=y

CONFIG_NFS_FSCACHE=y

CONFIG_NFS_USE_LEGACY_DNS=y

CONFIG_NFSD=y

CONFIG_NFSD_V2_ACL=y

CONFIG_NFSD_V3=y

CONFIG_NFSD_V3_ACL=y

CONFIG_NFSD_V4=y

CONFIG_NFSD_PNFS=y

CONFIG_NFSD_BLOCKLAYOUT=y

CONFIG_NFSD_SCSILAYOUT=y

CONFIG_NFSD_FLEXFILELAYOUT=y

CONFIG_NFSD_V4_SECURITY_LABEL=y

# CONFIG_NFSD_FAULT_INJECTION is not set

CONFIG_NFS_ACL_SUPPORT=y

CONFIG_NFS_COMMON=y

```

```
/usr/src/linux/ ps -fe | egrep "nfs|rpc"

root          64       2  0 11:32 ?        00:00:00 [rpciod]

root          71       2  0 11:32 ?        00:00:00 [nfsiod]

root         158       1  0 11:32 ?        00:00:00 /sbin/rpcbind -w -f

root       14662   13193  0 12:04 pts/0    00:00:00 /bin/grep -E nfs|rpc

```

Noch aus dem Systemd-Journal:

```
/usr/src/linux/ journalctl | grep nfs

Jan 08 22:35:44 After8 nfsidmap[107727]: libnfsidmap: using domain: Adlerhorst.local

Jan 08 22:35:44 After8 nfsidmap[107727]: libnfsidmap: Realms list: 'ADLERHORST.LOCAL'

Jan 08 22:35:44 After8 nfsidmap[107727]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

Jan 08 22:35:44 After8 nfsidmap[107727]: nss_getpwnam: name 'uhai@localdomain' does not map into domain 'Adlerhorst.local'

Jan 08 22:35:44 After8 nfsidmap[107728]: libnfsidmap: using domain: Adlerhorst.local

Jan 08 22:35:44 After8 nfsidmap[107728]: libnfsidmap: Realms list: 'ADLERHORST.LOCAL'

Jan 08 22:35:44 After8 nfsidmap[107728]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

Jan 08 22:35:44 After8 nfsidmap[107728]: nss_name_to_gid: name 'everyone@localdomain' does not map into domain 'Adlerhorst.local'
```

Da weichen wohl die Domains ab.... hatte ich auf dem Server aber schon mal angepasst, war aber nicht dauerhaft!?

OK, die Angaben zum Server:

```
~] #  grep -v "^#" /etc/idmapd.conf | grep "."

[General]

Verbosity = 9

Pipefs-Directory = /var/lib/nfs/rpc_pipefs

Domain = localdomain

[Mapping]

Nobody-User = guest

Nobody-Group = guest

[~] # 

```

Hier ist eine andere Domain aufgeführt....

```
[~] # cat /etc/exports                                                                                                                                 

"/share/CACHEDEV1_DATA/Download" *(ro,async,no_subtree_check,insecure,no_root_squash,fsid=501f3b4dcc958c926cc7ab8c1494fdc8) 

"/share/NFSv=4" *(no_subtree_check,no_root_squash,insecure,fsid=0)

"/share/NFSv=4/Download" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash,fsid=501f3b4dcc958c926cc7ab8c1494fdc8) 

"/share/CACHEDEV1_DATA/Multimedia" *(ro,async,no_subtree_check,insecure,no_root_squash,fsid=736fa5fd632febf0f01a7e3605a32d64) 

"/share/NFSv=4/Multimedia" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash,fsid=736fa5fd632febf0f01a7e3605a32d64) 

"/share/CACHEDEV1_DATA/homes/Natan" *(ro,async,no_subtree_check,insecure,no_root_squash,fsid=97728067531e949e085998102bdbe65d) 

"/share/NFSv=4/Natan" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash,fsid=97728067531e949e085998102bdbe65d) 

"/share/CACHEDEV1_DATA/Public" *(rw,async,no_subtree_check,insecure,no_root_squash,fsid=187f07688af237f648d8f7126f908066) 

"/share/NFSv=4/Public" *(rw,nohide,async,no_subtree_check,insecure,no_root_squash,fsid=187f07688af237f648d8f7126f908066) 

"/share/CACHEDEV2_DATA/Public1" *(rw,async,no_subtree_check,insecure,no_root_squash,fsid=b790a94ab07004ccd897f97084ae04ac) 

"/share/NFSv=4/Public1" *(rw,nohide,async,no_subtree_check,insecure,no_root_squash,fsid=b790a94ab07004ccd897f97084ae04ac) 

"/share/CACHEDEV1_DATA/Recordings" *(ro,async,no_subtree_check,insecure,no_root_squash,fsid=fcf753c054b5a0dd9d4a1cdff8fda863) 

"/share/NFSv=4/Recordings" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash,fsid=fcf753c054b5a0dd9d4a1cdff8fda863) 

"/share/CACHEDEV1_DATA/Web" *(ro,async,no_subtree_check,insecure,no_root_squash,fsid=10bf6c56af2aecfe26f873e0f6a75068) 

"/share/NFSv=4/Web" *(ro,nohide,async,no_subtree_check,insecure,no_root_squash,fsid=10bf6c56af2aecfe26f873e0f6a75068) 

"/share/CACHEDEV1_DATA/homes" *(rw,async,no_subtree_check,insecure,no_root_squash,fsid=ed7621f8976c7eea70e11bc87c45f88d) 

"/share/NFSv=4/homes" *(rw,nohide,async,no_subtree_check,insecure,no_root_squash,fsid=ed7621f8976c7eea70e11bc87c45f88d) 

"/share/CACHEDEV2_DATA/homes1" *(rw,async,no_subtree_check,insecure,no_root_squash,fsid=385c2383c301ed22888527b2bb522bad) 

"/share/NFSv=4/homes1" *(rw,nohide,async,no_subtree_check,insecure,no_root_squash,fsid=385c2383c301ed22888527b2bb522bad) 

"/share/CACHEDEV1_DATA/homes/uhai" *(rw,async,no_subtree_check,insecure,no_root_squash,fsid=ee35d84f02f93eb7c4d1b470c132cb1a) 

"/share/NFSv=4/uhai" *(rw,nohide,async,no_subtree_check,insecure,no_root_squash,fsid=ee35d84f02f93eb7c4d1b470c132cb1a)
```

```
 # zgrep -E "(Kernel Config|NFS)" /proc/config.gz

-sh: zgrep: command not found
```

Das Verzeichnis mit den Kernel-Sourcen konnte ich nicht finden, eventuell lädt QNA[/code]P die Kernel fertig auf die Systeme? Das hier kann ich Dir anbieten:

```
[~] # uname -a

Linux NAS 3.2.26 #2 SMP Thu Dec 12 05:30:28 CST 2019 armv7l unknown

```

lsmod | grep nfs liefert leider auch nichts..

```
[~] # ps -fe | egrep "nfs|rpc"

   23 admin           SW< [rpciod]

   28 admin           SW< [nfsiod]

 6566 admin       468 S   egrep nfs|rpc 

14761 admin       124 S   /usr/sbin/rpc.rquotad -p 30002 

15075 admin      1644 S   /usr/sbin/rpc.mountd -p 30000 -F 

15211 admin           SW< [nfsd4]

15212 admin           SW< [nfsd4_callbacks]

15213 admin           SW  [nfsd]

15214 admin           SW  [nfsd]

15215 admin           SW  [nfsd]

15216 admin           SW  [nfsd]

15219 admin           SW  [nfsd]

15220 admin           SW  [nfsd]

15222 admin           SW  [nfsd]

15224 admin           SW  [nfsd]

15381 admin       952 S   /usr/sbin/rpc.idmapd 

15404 admin       928 S   /usr/sbin/rpc.statd -p 30001 

```

Hier hatte ich die Domain schon mal geändert:

```
[~] # cat /etc/idmapd.conf

[General]

Verbosity = 9

Pipefs-Directory = /var/lib/nfs/rpc_pipefs

Domain = localdomain

[Mapping]

Nobody-User = guest

Nobody-Group = guest

```

Nach einem Neustart war das aber wieder überschrieben....

Kannst Du damit schon etwas anfangen? oder kannst Du mir den "Weg zum Kernel" bei QNAPs QTS weisen?

uhai

----------

## mike155

Hallo uhai,

danke für die Daten. Abgesehen von den unterschiedlichen Domains habe ich nichts gefunden, was offensichtlich falsch ist.

Zuallererst solltest Du das Problem mit den unterschiedlichen Domains lösen. Server und Client müssen die gleiche NFS Domain haben. Die Fehlermeldung

```
Jan 10 19:19:15 After8 nfsidmap[232378]: nss_getpwnam: name 'uhai@localdomain' does not map into domain 'Adlerhorst.local'

Jan 10 19:19:15 After8 nfsidmap[232379]: libnfsidmap: using domain: Adlerhorst.local

Jan 10 19:19:15 After8 nfsidmap[232379]: libnfsidmap: Realms list: 'ADLERHORST.LOCAL'

Jan 10 19:19:15 After8 nfsidmap[232379]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

Jan 10 19:19:15 After8 nfsidmap[232379]: nss_name_to_gid: name 'everyone@localdomain' does not map into domain 'Adlerhorst.local'
```

sollte dann verschwinden. Möglicherweise ist dann auch das I/O-Problem gelöst.

 *Quote:*   

> /homes und /Public sind von einer alten Konfiguration, die ich als "Fallback" noch vorhalte. Das hatte funktioniert, bis ich die QNAP mit neuen Laufwerken erweitert habe. userid und gid waren auf client und server identisch gewesen. Da die Laufwerke (Raid) bereits vollsind, musste ich neue Laufwerke ergänzen. Sobald ich /homes1 und /Public1 auf dem neuen Raid sauber benutzen kann werden die alten Freigaben entfernt und diese Verzeichnisse auf der NAS gelöscht. 

 

Ich kann zwar nicht sagen, dass das falsch ist - aber ich würde es nicht machen. Ich würde meine Export-Liste so einfach wie möglich halten. Es könnte zu Problemen führen, wenn Du das gleiche Verzeichnis mehrfach exportierst. NFS hat so seine Eigenheiten...

Es wundert mich, dass die Ports für die RPC-Dienste auf dem QNAP explizit angegeben werden (auf meinem NFS-Server ist das nicht so):

```
14761 admin       124 S   /usr/sbin/rpc.rquotad -p 30002

15075 admin      1644 S   /usr/sbin/rpc.mountd -p 30000 -F

15404 admin       928 S   /usr/sbin/rpc.statd -p 30001
```

Das kann völlig in Ordnung sein - vielleicht macht QNAP das einfach so. Es kann aber auch sein, dass QNAP die Ports für die RPC-Dienste explizit setzt, weil die Ports von Dir in irgendeiner Maske oder Konfigurationsdatei konfiguriert wurden. Falls das so sein sollte: entferne diese Konfiguration wieder und lasse QNAP die Standard-Ports verwenden. 

Es könnte sein, dass in Deinem Setup NFSv3 besser ist NFSv4. NFSv3 ist einfacher und stabiler als NFSv4. Ein Wechsel zu NFSv3 wäre auf jeden Fall eine Rückfallmöglichkeit, falls sich die Probleme mit NFSv4 nicht lösen lassen. Versuche aber zuerst, NFSv4 zum Laufen zu bekommen.

Mike

----------

## uhai

Danke Mike155,

auf der QNAP habe ich schon versucht, die Domain anzupassen. nach einem Neustart war das aber wieder weg. Das QNAP-Forum ist leider nicht so gut wie das Gentoo-Forum.... Irgendwo in der Oberfläche war der Domainname auch einzustellen, das habe ich aber bisher nicht wiedergefunden.

home und Public habe ich vom alten Raid auf den neuen Raid der NAS kopiert und in home1 und Public1 genannt. Also sind das auch auf der NAS zwei verschiedene Dateiverzeichnisse...

Die ports für rpc habe ich nicht bewußt geändert.... das lasse ich mal so.

Braucht nfs4 ein mapping-file für die user? Falls ja, wie heißt das? Bei nfs 3 muss ich nur die user-id und group-id gleichsetzen und ggfs. auf client oder server mit chown die Änderungen einspielen... oder habe ich das falsch in Erinnerung?

uhai

----------

## mike155

Wenn Du den NFS Domain-Namen auf dem QNAP nicht ändern kannst, dann ändere ihn doch auf dem Client. 

Editiere die Datei /etc/idmapd.conf auf dem Client und setze dort den NFS Domain-Namen, den Dein NFS Server (QNAP) vorgibt.

----------

## uhai

Fast gut:

aus nobody:nobody ist uhai:nobody geworden.... vermutlich muss ich die groups noch angleichen? Digikam kann die Vollansichten noch immer nicht öffnen....

uhai

----------

## mike155

Das sieht ja schon mal nach einem Schritt in die richtige Richtung aus! Jetzt müssen wir herausfinden, wie das Mapping funktioniert. Bekommst Du noch Fehlermeldungen in den Log-Dateien?

Log Dich bitte auf dem CLIENT ein und wechsle mit "cd" in das Verzeichnis, in dem die Vollansichten liegen. Gib bitte folgendes ein und poste die Ausgabe.

```
touch a

ls -la a 

ls -lan a

ls -la <Datei-Name eines Bildes, das Du nicht öffnen kannst>

ls -lan <Gleicher Dateiname wie eben>

ls -lad . ..

ls -ladn . ..

```

Dann gehe auf den SERVER und wechsle mit cd in das gleiche Verzeichnis. Gib bitte folgendes ein und poste die Ausgabe.

```
touch b

ls -la a b

ls -lan a b

ls -la <Gleicher Dateiname eines Bildes, den Du oben schon verwendet hast>

ls -lan <Gleicher Dateiname eines Bildes, den Du oben schon verwendet hast>

ls -lad . ..

ls -ladn . ..
```

----------

## uhai

Seltsam, die verschiedenen Domains haben die Änderung der idmapd.conf (client) und den Reboot offensichtlich überstanden, den Fehler gibt es noch immer auf dem client:

```

/home/uhai/ journalctl | grep nfs

Jan 08 22:35:44 After8 nfsidmap[107727]: libnfsidmap: using domain: Adlerhorst.local

Jan 08 22:35:44 After8 nfsidmap[107727]: libnfsidmap: Realms list: 'ADLERHORST.LOCAL'

Jan 08 22:35:44 After8 nfsidmap[107727]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

Jan 08 22:35:44 After8 nfsidmap[107727]: nss_getpwnam: name 'uhai@localdomain' does not map into domain 'Adlerhorst.local'

Jan 08 22:35:44 After8 nfsidmap[107728]: libnfsidmap: using domain: Adlerhorst.local

Jan 08 22:35:44 After8 nfsidmap[107728]: libnfsidmap: Realms list: 'ADLERHORST.LOCAL'

Jan 08 22:35:44 After8 nfsidmap[107728]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

Jan 08 22:35:44 After8 nfsidmap[107728]: nss_name_to_gid: name 'everyone@localdomain' does not map into domain 'Adlerhorst.local'

```

Auf dem Server habe ich einen Fehler im network-log:

```
cat /var/log/network/err.log     

[2020-02-03 12:52:00] [main.log] cmd(/sbin/hal_app --se_sys_set_sfp_params) failed, ret=255
```

Das fand ich allerdings interessant:

```
~] # cat /var/log/network/write_hosts     

[2020-02-03 13:02:29] write_hosts()

[2020-02-03 13:02:29] c_callback_funcs()

[2020-02-03 13:02:29] exit "network.sh write_hosts", ret=0

[2020-02-03 13:02:29] ------------------------------------------------

```

Eventuell schreibt network.sh die domain beim start immer neu?? Ich habe nicht viel von der Batch-Datei verstanden, aber das hier gefunden:

```

[ "x${dns1}" = "x" ] && dns1="8.8.8.8"

  [ "x${dns2}" = "x" ] && dns2="8.8.4.4"

  domain=$(/bin/cat /etc/resolv.conf 2>/dev/null | /bin/grep domain | /bin/awk 'NR==1{print $2}')

  

  [ "x$(/bin/cat /etc/resolv.conf 2>/dev/null | /bin/grep nameserver | /bin/awk 'NR==1{print $2}')" != "x${dns1}" ] && rewrite_conf=1

  [ "x$(/bin/cat /etc/resolv.conf 2>/dev/null | /bin/grep nameserver | /bin/awk 'NR==2{print $2}')" != "x${dns2}" ] && rewrite_conf=1

  

  if [ "x${IPV6}" = "xTRUE" ]; then

    dns1_v6=`/sbin/getcfg "Network" "IPV6 Domain Name Server 1" -d "2001:4860:4860::8888"`

    dns2_v6=`/sbin/getcfg "Network" "IPV6 Domain Name Server 2" -d "2001:4860:4860::8844"`

    [ "x$(/bin/cat /etc/resolv.conf 2>/dev/null | /bin/grep nameserver | /bin/awk 'NR==3{print $2}')" != "x${dns1_v6}" ] && rewrite_conf=1

    [ "x$(/bin/cat /etc/resolv.conf 2>/dev/null | /bin/grep nameserver | /bin/awk 'NR==4{print $2}')" != "x${dns2_v6}" ] && rewrite_conf=1

  else

    [ "x$(/bin/cat /etc/resolv.conf 2>/dev/null | /bin/grep nameserver | /bin/awk 'NR==3{print $2}')" != "x" ] && rewrite_conf=1

    [ "x$(/bin/cat /etc/resolv.conf 2>/dev/null | /bin/grep nameserver | /bin/awk 'NR==4{print $2}')" != "x" ] && rewrite_conf=1

  fi

  

  if [ "x${rewrite_conf}" != "x0" ]; then

    dbg "write dns1=${dns1}, dns2=${dns2} to /etc/resolv.conf"

    /bin/echo "nameserver ${dns1}" > /etc/resolv.conf

    /bin/echo "nameserver ${dns2}" >> /etc/resolv.conf

    if [ "x${IPV6}" = "xTRUE" ]; then

      dbg "write dns1_v6=${dns1_v6}, dns2_v6=${dns2_v6} to /etc/resolv.conf"

      /bin/echo "nameserver ${dns1_v6}" >> /etc/resolv.conf

      /bin/echo "nameserver ${dns2_v6}" >> /etc/resolv.conf

    fi

    if [ "x${domain}" != "x" ] && [ "x${domain}" != "xdev.null" ]; then

      dbg "write domain=${domain} to /etc/resolv.conf"

      /bin/echo "domain ${domain}" >> /etc/resolv.conf

    fi

  fi

```

In der resolv.conf ist aber keine Domain angegeben:

```
[/] # cat /etc/resolv.conf

nameserver 192.168.0.1

nameserver 78.42.43.41

nameserver 2001:4f8:0:2::14

nameserver 2a00:1838:20:1::b29c:ca35

```

Jedenfalls werden alle Netzwerk-Konfigurationen beim STart gelöscht und enu geschrieben. Selbst die network.sh wird überprüft und bei Änderungen aus einer network.bak wiederhergestellt.... Macht einen sicheren Eindruck. D.h. aber ich muss die Konfiguration möglichst in der grafishcen oberfläche ändern, damit die Variablen im Hintergrund richtig gesetzt werden und nach einem reboot auch zur Verfügung stehen.

Im augenblick hat der client die Server-Verzeichnisse nicht gemounted...:

```
Feb 03 12:52:56 After8 systemd[1]: home-uhai-NAS.mount: Mounting timed out. Terminating.

Feb 03 12:52:56 After8 systemd[1]: home-uhai-NAS.mount: Mount process exited, code=killed, status=15/TERM

Feb 03 12:52:56 After8 systemd[1]: home-uhai-NAS.mount: Failed with result 'timeout'.

Feb 03 12:52:56 After8 systemd[1]: Failed to mount /home/uhai/NAS.

Feb 03 12:52:56 After8 systemd[1]: home-uhai-public.mount: Mounting timed out. Terminating.

Feb 03 12:52:56 After8 systemd[1]: home-uhai-public.mount: Mount process exited, code=killed, status=15/TERM

Feb 03 12:52:56 After8 systemd[1]: home-uhai-public.mount: Failed with result 'timeout'.

Feb 03 12:52:56 After8 systemd[1]: Failed to mount /home/uhai/public.

```

Reboot tut gut - dann mal sehen....

uhai

----------

## mike155

In /etc/resolv.conf wird die DNS Domain konfiguriert. Die hat mit NFS erst einmal nichts zu tun. Die Fehlermeldung, die Du immer wieder bekommst, handelt von der NFS Domain. Bitte trenne diese unterschiedlichen Domains gedanklich!

Es kann natürlich Wechselwirkungen zwischen DNS und NFS geben. Wenn DNS nicht sauber eingerichtet ist, kann es sein, dass NFS nicht funktioniert, weil Client und Server sich nicht finden (trifft bei Dir nicht zu, weil Client und Server ja miteinander kommunizieren können). Und es wäre möglich, dass NFS die DNS Domain verwendet, wenn keine NFS Domain konfiguriert ist (unwahrscheinlich, aber möglich). Von daher sollte man DNS auf jeden Fall sauber konfigurieren.

Ansonsten müsstest Du herausfinden, wieso immer wieder "Adlerhorst.local" verwendet wird. Die Fehlermeldung 

```
name 'everyone@localdomain' does not map into domain 'Adlerhorst.local'
```

sagt ja ganz deutlich, dass er den User nicht mappen kann. Das ist der Grund, warum die Berechtigungen auf dem Client nicht stimmen. Wenn Du dieses Problem löst, wirst Du auch das Berechtigungsproblem lösen.

----------

## uhai

OK. Reboot und Laufwerke sind wieder auf dem client  da....

So sieht das auf dem client aus:

```
 ls -al NAS/Fotos

[....]

-rwxrwx---   1 uhai nobody    3444520  7. Feb 2015   rimg0009.PNG

[...]

```

Und so auf dem Server:

```
ls -al /share/CACHEDEV2_DATA/homes1/uhai/Fotos

[...]

-rwxrwx---    1 uhai     everyone   3444520 Feb  7  2015 rimg0009.PNG*

[...]

```

Abgesehen davon, dass die Bilder wohl nicht ausführbar sein müßten (?) - was bedeutet das Sternchen hinter der Anzeige auf dem Server?

Zu den Punkten, die Du angefordert hast: Auf den Server komme ich mit ssh nur als admin. Auf dem client bin ich als user.

OK, hier kommen ide Angaben für den Client:

```
uhai@After8 ~ $ touch rimg0009.PNG

uhai@After8 ~ $                           

```

```
[uhai@After8 ~ $ ls -la rimg0009.PNG

-rw-r--r-- 1 uhai uhai 0  3. Feb 15:51 rimg0009.PNG
```

Hier scheint das "x" nicht mehr angezeigt????

```
uhai@After8 ~ $ ls -lan rimg0009.PNG

-rw-r--r-- 1 1000 1000 0  3. Feb 15:51 rimg0009.PNG

```

rimg0009.PNG kann ich nicht in der Vollansicht öffnen. Das geht mit keinem Bild mehr. Ich habe mich beim Eingangspost vermutlich schon vertan... die Vorschaubilder sind teilweise nicht vorhanden und zwar bei den zuletzt von der SD-Karte geladenen Fotos. Vermutlich konnten die Dateien nicht auf dem Server geschrieben werden und daher wurden auch die Vorschaubilder nicht erstellt. Der Zugriff auf den MYSQL-Server hat aber wohl geklappt, der Eintrag für die neuen Bilder ist jedenfalls da. Vermutlich bin ich da durcheinander gekommen.

```
uhai@After8 ~ $ ls -lad . ..

drwxr-xr-x 73 uhai users 4096  3. Feb 15:37 .

drwxr-xr-x  3 root root  4096 16. Apr 2017  ..
```

```
uhai@After8 ~ $ ls -ladn . ..

drwxr-xr-x 73 1000 100 4096  3. Feb 15:38 .

drwxr-xr-x  3    0   0 4096 16. Apr 2017  ..

```

Das war client,

jetzt kommt Server:

```

[/] # touch logo.png

[/] # 

```

 ACHTUNG: bin eingelogt als admin über ssh!

```
[/share/CACHEDEV2_DATA/homes1/uhai/Fotos] # ls -la rimg0009.PNG logo.png

-rwxrwx---    1 uhai     everyone     20385 Feb  7  2015 logo.png*

-rwxrwx---    1 uhai     everyone   3444520 Feb  7  2015 rimg0009.PNG*
```

```
[/share/CACHEDEV2_DATA/homes1/uhai/Fotos] # ls -lan rimg0009.PNG logo.png

-rwxrwx---    1 1000     100         20385 Feb  7  2015 logo.png*

-rwxrwx---    1 1000     100       3444520 Feb  7  2015 rimg0009.PNG*

```

```
[/share/CACHEDEV2_DATA/homes1/uhai/Fotos] # ls -la rimg0009.PNG          

-rwxrwx---    1 uhai     everyone   3444520 Feb  7  2015 rimg0009.PNG*

```

```
[/share/CACHEDEV2_DATA/homes1/uhai/Fotos] # ls -lan rimg0009.PNG       

-rwxrwx---    1 1000     100       3444520 Feb  7  2015 rimg0009.PNG*

```

```
[/share/CACHEDEV2_DATA/homes1/uhai/Fotos] # ls -lad . ..

drwxrwx---   59 uhai     everyone     12288 Jan  7 21:37 ./

drwxrwx---    8 uhai     everyone      4096 Nov 21 17:01 ../

```

```
[/share/CACHEDEV2_DATA/homes1/uhai/Fotos] # ls -ladn . ..

drwxrwx---   59 1000     100         12288 Jan  7 21:37 ./

drwxrwx---    8 1000     100          4096 Nov 21 17:01 ../

```

Ende Server

uhai

----------

## mike155

uhai, danke für die ls-Ausgaben! 

Ich bin jetzt etwas verwirrt. Kommen folgende Fehlermeldungen noch?

```
Jan 08 22:35:44 After8 nfsidmap[107727]: libnfsidmap: using domain: Adlerhorst.local

Jan 08 22:35:44 After8 nfsidmap[107727]: libnfsidmap: Realms list: 'ADLERHORST.LOCAL'

Jan 08 22:35:44 After8 nfsidmap[107727]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

Jan 08 22:35:44 After8 nfsidmap[107727]: nss_getpwnam: name 'uhai@localdomain' does not map into domain 'Adlerhorst.local'

Jan 08 22:35:44 After8 nfsidmap[107728]: libnfsidmap: using domain: Adlerhorst.local

Jan 08 22:35:44 After8 nfsidmap[107728]: libnfsidmap: Realms list: 'ADLERHORST.LOCAL'

Jan 08 22:35:44 After8 nfsidmap[107728]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

Jan 08 22:35:44 After8 nfsidmap[107728]: nss_name_to_gid: name 'everyone@localdomain' does not map into domain 'Adlerhorst.local'
```

Oder ist das Problem gelöst? Falls diese Meldungen noch kommen, sollte zuerst dieses Problem gelöst werden. Die NFS Domain muss auf Server und Client übereinstimmen und diese Meldungen dürfen nicht mehr erscheinen. Vorher ist es nicht sinnvoll, an einer anderen Stelle weiterzusuchen.

Wenn/Falls das Problem gelöst ist, können wir die ls-Ausgaben analysieren.

----------

## uhai

Problem ist nicht gelöst, domains aber gleich... bin ratlos. Anscheinend holt er für die user die domain woanders her.

Ich habe jetzt auf client und server /etc/hosts und /etc/idmapd.conf angepasst:

Client:

```
/home/uhai/ hostname -d

Adlerhorst.local

root@After8 Di Feb 04 08:40:51 

/home/uhai/ hostname -f

After8.Adlerhorst.local

```

Server:

```
[~] # hostname -d      

Adlerhorst.local

[~] # hostname -f

NAS.Adlerhorst.local

```

Fehler bleibt:

```
Jan 08 22:55:51 After8 nfsidmap[108411]: libnfsidmap: using domain: Adlerhorst.local

Jan 08 22:55:51 After8 nfsidmap[108411]: libnfsidmap: Realms list: 'ADLERHORST.LOCAL'

Jan 08 22:55:51 After8 nfsidmap[108411]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

Jan 08 22:55:51 After8 nfsidmap[108411]: nss_getpwnam: name 'uhai@localdomain' does not map into domain 'Adlerhorst.local'

Jan 08 22:55:51 After8 nfsidmap[108412]: libnfsidmap: using domain: Adlerhorst.local

Jan 08 22:55:51 After8 nfsidmap[108412]: libnfsidmap: Realms list: 'ADLERHORST.LOCAL'

Jan 08 22:55:51 After8 nfsidmap[108412]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch

Jan 08 22:55:51 After8 nfsidmap[108412]: nss_name_to_gid: name 'everyone@localdomain' does not map into domain 'Adlerhorst.local'
```

Ich bin nicht sichere, ober der Server die domain-Anpassung mitbekommen hat. Kann ich die Konfigurationen manuell einlesen lassen?

uahi

----------

## Tyrus

Über das Arch-Wiki unter Enabling NFSv4 idmapping hab ich folgendes gefunden:

Why NFSv4 UID mapping breaks with AUTH_UNIX

Die schreiben im Arch-Wiki:

 *Quote:*   

> 
> 
> Note:
> 
>     NFSv4 idmapping does not work with the default sec=sys mount option. 
> ...

 

OpenSuse hat auch darüber geschrieben:

https://www.suse.com/support/kb/doc/?id=7014266

Du kannst ja mal testweise versuchen was sie vorschlagen:

```

It can also be set on-the-fly with:

 

echo 1 > /sys/module/nfs/parameters/nfs4_disable_idmapping

    (However, it will only impact mounts performed after it is set.  It will be necessary to umount and remount existing nfs4 mounts.)

```

----------

## uhai

Danke, das habe ich schon gefunden und auch ausprobiert.

Mein Problem ist momentan, dass auf client und Server die domain "Adlerhorst.local" gesetzt ist, in der Fehlmeldung aber "uhai@localhost" bzw. "everyone@localhost" auftaucht. Wo kommt der localhost noch her?

uhai

----------

## Tyrus

Ich denke das liegt daran das localdomain eine Defaulteinstellung ist die in libnfsidmap.c gesetzt wird:

```

[...]

#ifndef IDMAPD_DEFAULT_DOMAIN

#define IDMAPD_DEFAULT_DOMAIN "localdomain"

#endif

[...]

```

BTW der Fehler lautet:

```

...

nss_getpwnam: name 'uhai@localdomain' does not map into domain 'Adlerhorst.local' 

...

nss_name_to_gid: name 'everyone@localdomain' does not map into domain 'Adlerhorst.local'

```

Wo hast du das @localhost her?

----------

## uhai

Die Domain habe ich in /etc/hosts, /etc/resolv.conf und /etc/idmapd.conf gesetzt.... Ich dachte, da habe ich alle Stellen erwischt. nfs4 zieht aber alle user als user@localdomain.... ???

uhai

----------

## uhai

Ok, ich komme nicht weiter, also fass ich mal zusammen, was ich bisher verstanden habe:

Ausgelöst wird das Problem wohl durch das user-mapping durch nfs4. Bei aktiviertem idmapd vergleicht nfs4 user@domain. Bei mir taucht da imemr noch "localdomain" auf. Keine Ahnung wo das herkommt.

nfs3 hat legihglich die userid und groupid verglichen. Das ist auch das Verhalten von nfs4 bei deaktivierten idmapping (=default). Also müsste es laufen, wenn ich userid und groupid auf server & client gleich habe. So hat das bisher auch geklappt.

Auf dem server ist:

```
[~] # id uhai

uid=1000(uhai) gid=100(everyone)
```

Auf dem client ist:

```
 id uhai

uid=1000(uhai) gid=100(users) Gruppen=100(users),7(lp),10(wheel),18(audio),19(cdrom),27(video),85(usb),1000(uhai),35(games),103(plugdev),102(scanner)

```

Das sollte doch passen, oder?

Auf dem client läuft der resolver:

```
 dmesg | grep id_resolver

[    0.544612] NFS: Registering the id_resolver key type

[    0.544617] Key type id_resolver registered

```

auf dem Server nicht:

```
[~] # dmesg | grep id_resolver

[~] #        

```

D.h. entweder stoppe ich den resolver auf dem client und gehe wieder über die ids oder ich starte den resolver auf dem server...

Soweit richtig?

uhai

----------

## mike155

Ich würde NFSv4 auf dem QNAP ausschalten und zu NFSv3 zurückgehen. Neuer heißt nicht immer "besser" - und wenn's nicht geht, dann geht's nicht...

----------

## uhai

So, bin zurück auf nfs3 und läuft....

vielen herzlichen Dank für Deine Unterstützung und Ausdauer Mike155. 

Mich ärgert nur ein bisschen, dass ich es auch mit Hilfe aus dem Forum nicht hinbekommen habe, tagelang recherchiert und gelesen habe... und noch nicht einmal eine Idee habe, woran das liegen könnte. 

uhai

----------

