netatalk problemen

[nicket84]

Geachte bezoekers,

Ik heb alle netatalk topics doorgespit, maar heb daar geen soortelijk probleem, laat staan een oplossing gevonden.

Ik heb een WS 800mhz CPU 256mb geheugen en 160gb HD met daarop SuSE 9.3 (voorheen 9.2) met de onderstaande services geinstalleerd.

services info
- Samba
- Netatalk
- Apache
- MySQL
- SuSE Firewall2 (die tijdelijk uit staat, totdat het probleem verholpen is)

versie info
kernel: 2.6.11
netatalk: 2.0

De data die ik gebruik is van de vorige SuSE 9.2 server afgehaald, en het eerste probleem (wat ik denk daar mee te maken te hebben) zit hem hier:

May 19 09:26:10 MACELIENTJE afpd[18364]: WARNING: volume encoding ISO-8859-1 is *not* supported by netatalk, expect problems !!!!

Deze melding krijg ik in /var/log/messages te zien. Ik heb de netatalk scripts ook al ingesteld op UTF-8, maar dat geeft het zelfde effect.

Ook lijkt er iets met de CNID schema te zijn:

May 19 09:26:10 MACELIENTJE afpd[18364]: Warning: No CNID scheme for volume /share/mac. Using default.
May 19 09:26:10 MACELIENTJE afpd[18364]: Setting uid/gid to 0/0
May 19 09:26:10 MACELIENTJE afpd[18364]: CNID DB initialized using Sleepycat Software: Berkeley DB 4.3.27: (March 19, 2005)

Ik heb diversen script getest, en ik blijf de zelfde problemen houden. Ook hebben de Mac machines sinds deze week ( na 4weken zonder problemen ) last dat de server verbinding wegvalt met de volgende melding in het log:

May 19 09:14:22 MACELIENTJE afpd[18285]: dsi_stream_write: Broken pipe
May 19 09:14:22 MACELIENTJE afpd[18285]: Connection terminated
May 19 09:14:22 MACELIENTJE afpd[13751]: server_child[1] 18285 exited 1
May 19 09:14:22 MACELIENTJE afpd[18261]: afp_die: asp_shutdown: Connection timed out

Hier vind je mijn scripts:

afpd.conf

code:

Vollumes.default -systemvol /etc/netatalk/AppleVolumes.system

#"MACTEST" - -transall -maccodepage mac_cyrillic -unixcodepage utf8

#"testutf" unicov -c cdb -f -ISO-8859-1 -t UTF8 -m MAC_ROMAN /share/mac

"MACELIENTJE" -uamlist uams_guest.so -sysvol </share/mac> -icon -loginmsg "Welkom op MACELIENTJE!"

atalkd.conf

code:

eth0 -phase 2 -net 0-65534 -addr 65120.64

netatalk.conf

code:

ATALK_MAC_CHARSET='MAC_ROMAN'
ATALK_UNIX_CHARSET='LOCALE'

# specify this if you don't want guest, clrtxt, and dhx
# available options: uams_guest.so, uams_clrtxt.so, uams_dhx.so,
#                    uams_randnum.so
#AFPD_UAMLIST="-U uams_clrtxt.so,uams_dhx.so"

# Change this to set the id of the guest user
AFPD_GUEST=nobody

# Set which daemons to run (papd is dependent upon atalkd):
ATALKD_RUN=yes
PAPD_RUN=no
CNID_METAD_RUN=yes
AFPD_RUN=yes
TIMELORD_RUN=no
A2BOOT_RUN=no

# Control whether the daemons are started in the background
ATALK_BGROUND=no

# export the charsets, read form ENV by apps
export ATALK_MAC_CHARSET
export ATALK_UNIX_CHARSET

AppleVolumes.default

code:

/share/mac "macelientje" adouble:v1 volcharset:ISO-8859-1

Ik hoop dat jullie zien wat er fout zit...

Alvast hartelijk bedankt!

[Xandrios]

Professional Networking & Servers ==> Non-Windows Operating Systems

[osx]

vollumes.default met 2 ellen? (eerste regel afpd.conf)

Is dit een typo hier op got of staat het ook echt zo in je config file?

[nicket84]

osx schreef op donderdag 19 mei 2005 @ 12:17:
vollumes.default met 2 ellen? (eerste regel afpd.conf)

Is dit een typo hier op got of staat het ook echt zo in je config file?

is een rechtstreekse kopie... zal die dubbele L ff weghalen

edit:

daar zat nog een stuk script voor met een # (dus deze word niet gebruikt)
Daar ligt het dus niet aan...

[ Voor 18% gewijzigd door nicket84 op 19-05-2005 12:46 ]

[usr-local-dick]

Als ik het goed begrijp wil je netatalk-data van een server naar een andere migreren?
De recommended way is dan alles eerst naar een Mac kopieren, en daarna weer terug...

Wat voor versie netatalk draaide op de oude server? Dat is nl. super belangrijk om te weten...

[usr-local-dick]

Ook lijkt er iets met de CNID schema te zijn:

May 19 09:26:10 MACELIENTJE afpd[18364]: Warning: No CNID scheme for volume /share/mac. Using default.
May 19 09:26:10 MACELIENTJE afpd[18364]: Setting uid/gid to 0/0
May 19 09:26:10 MACELIENTJE afpd[18364]: CNID DB initialized using Sleepycat Software: Berkeley DB 4.3.27: (March 19, 2005)

Dit is geen error maar een melding. Je hebt geen CNID schema opgegeven voor die share, en nu neemt hij de default (wat standaard dbd is). Als je deze melding niet meer wilt zien definieer je dat dus zelf in AppleVolumes.default.
Overigens, bij mijn weten is de syntax van die file: <dir> <opties> <sharenaam>.
Wat jij hebt klopt (denk ik) niet:

/share/mac "macelientje" adouble:v1 volcharset:ISO-8859-1

Ik zou dit eens proberen:

/share/mac cnidscheme:dbd "macelientje"

Die adouble:v1 en volcharset daar durf ik niets over te zeggen, ik speel altijd op safe en kopieer heen en weer tussen een Mac en de server....

Nog een ding: upgrade even naar 2.0.3, die is net eergister uitgekomen en fixt problemen met OSX 10.4.x ...

[ Voor 12% gewijzigd door usr-local-dick op 19-05-2005 14:36 ]

[nicket84]

Nee ik heb deze data van een mac (os9) naar een linuxserver met netatalk 1.6 gestuurd. Van daaruit de data naar een ext HD gestuurd (fat32)

En toen weer naar deze linuxserver met netatalk2.0 (waar de data op moet blijven staan)

[CyBeR]

Erhm...

May 19 09:26:10 MACELIENTJE afpd[18364]: WARNING: volume encoding ISO-8859-1 is *not* supported by netatalk, expect problems !!!!

En dan:

/share/mac "macelientje" adouble:v1 volcharset:ISO-8859-1

Ligt 't nou aan mij of is dat eerste probleem zo op te lossen?

[nicket84]

CyBeR schreef op donderdag 19 mei 2005 @ 15:13:
Erhm...


[...]


En dan:

[...]


Ligt 't nou aan mij of is dat eerste probleem zo op te lossen?

Jah ik weet dat het daar ingesteld staat, maar wat moet ik er dan van maken? Bij UTF-8 krijg ik de zelfde fout... Maar dan natuurlijk UTF-U ipv ISOxxx in de log

[usr-local-dick]

Nee ik heb deze data van een mac (os9) naar een linuxserver met netatalk 1.6 gestuurd. Van daaruit de data naar een ext HD gestuurd (fat32)
En toen weer naar deze linuxserver met netatalk2.0 (waar de data op moet blijven staan)

Dat upgrade pad is niet gesupport. De reden ervaar jij nu
Heb je die data nog ergens op een Mac staan?

[nicket84]

usr-local-dick schreef op donderdag 19 mei 2005 @ 15:33:
[...]


Dat upgrade pad is niet gesupport. De reden ervaar jij nu
Heb je die data nog ergens op een Mac staan?

Jah, maar het is 70gb aan data, En een groot aantal bestanden zijn gewijzigd.. Dus dat is geen optie...

[usr-local-dick]

Jah, maar het is 70gb aan data, En een groot aantal bestanden zijn gewijzigd.. Dus dat is geen optie...

Oh het is maar 70 Gb
Wat je ook nog kan doen (als je in ieder geval maar files kan lezen), is alles er nu vanaf trekken naar een Mac, dan shares deleten, opnieuw starten met de nieuwe lege netatalk2 shares.

[nicket84]

usr-local-dick schreef op donderdag 19 mei 2005 @ 16:17:
[...]


Oh het is maar 70 Gb
Wat je ook nog kan doen (als je in ieder geval maar files kan lezen), is alles er nu vanaf trekken naar een Mac, dan shares deleten, opnieuw starten met de nieuwe lege netatalk2 shares.

Dat heeft (neem ik aan) geen effect op de fouten in het log bestand.. De bestanden zijn lees,schrijf, uitvoerbaar.. Dat is het punt niet, maar de verbinding wil welleens wegvallen..

En ik weet niet wat die nare meldingen in het log bestand voor vervolgen kunnen geven..

[usr-local-dick]

Dat heeft (neem ik aan) geen effect op de fouten in het log bestand.. De bestanden zijn lees,schrijf, uitvoerbaar.. Dat is het punt niet, maar de verbinding wil welleens wegvallen..
En ik weet niet wat die nare meldingen in het log bestand voor vervolgen kunnen geven..

Vervolgens mij begrijpen we elkaar niet
Die fouten in het logbestand zijn echte errors. Je vraagt je af wat voor gevolgen die kunnen hebben? Zoals het er nu voor staat is het een kwestie van tijd voor je bestanden echt stuk/kwijt raken. Daarom is mijn aanpak: alles files zo snel mogelijk van die server afhalen naar een native Apple (liefst OSX) computer. Als 70 Gb niet past dan hang je er een externe schijf aan.

Zodra je alles geredt hebt, dan kun je alle data weggooien van de netatalk server (want die is zeker weten corrupt), en dan opnieuw beginnen met netatalk-2.x shares.
Dan alles terug kopieren en je data staat weer save op die server.

Dat die verbinding af en toe wegvalt komt juist doordat de data op disk in een ander formaat is dat de afpd daemon verwacht, hij kan het database formaat niet handelen en knalt er gewoon uit. Dus weer een reden om zo snel mogelijk je data naar een Mac te redden.

[nicket84]

usr-local-dick schreef op vrijdag 20 mei 2005 @ 10:32:
[...]


Vervolgens mij begrijpen we elkaar niet
Die fouten in het logbestand zijn echte errors. Je vraagt je af wat voor gevolgen die kunnen hebben? Zoals het er nu voor staat is het een kwestie van tijd voor je bestanden echt stuk/kwijt raken. Daarom is mijn aanpak: alles files zo snel mogelijk van die server afhalen naar een native Apple (liefst OSX) computer. Als 70 Gb niet past dan hang je er een externe schijf aan.

Zodra je alles geredt hebt, dan kun je alle data weggooien van de netatalk server (want die is zeker weten corrupt), en dan opnieuw beginnen met netatalk-2.x shares.
Dan alles terug kopieren en je data staat weer save op die server.

Dat die verbinding af en toe wegvalt komt juist doordat de data op disk in een ander formaat is dat de afpd daemon verwacht, hij kan het database formaat niet handelen en knalt er gewoon uit. Dus weer een reden om zo snel mogelijk je data naar een Mac te redden.

Oeh bedankt voor de info!!! Heb net snel een firewire kaartje gehaald, en ben alle data naar een linux disk aan het kopieren..

Dadelijk een mac ext hd en de linux ext hd op de mac aansluiten en kopieren... Dan zou de codering goed moeten zijn ofniet ?

Uuh.. als ik deze data uiteindelijk van de mac gekopieerd heb... Welke codering moet ik dan gebruiken voor nettalk UTF-8 of die ISO code.. of iets anders???

bedankt voor je hulp