NFS problemen

[ddv]

Ik heb een aantal problemen met gebruik van NFS op mijn server/client. Ik was bezig met het transferen van een aantal bestanden. Maar toen hij op 61% kwam kreeg ik ineens de melding: Access Denied. Wat kan ik hier tegen doen? Beide kernels zijn gecompiled met de volgende opties:

<*> NFS file system support
• Provide NFSv3 client support
<*> NFS server support
• Provide NFSv3 server support
• Provide NFS server over TCP support

Verder heb ik nfs-utils gemerged en de init scripts (nfs) toegevoegd aan de default runlevel.
En 192.168.1.2:/mnt/raid etc toegevoegd aan /etc/fstab. Dit word allemaal zonder problemen uitgevoerd en ik kan hem dan ook gewoon bereiken.

Verder staat er dit in /etc/exports:

/mnt/raid 192.168.1.3(rw,sync)

edit:

Dit probleem schijnt zich nu niet meer voor te doen.

[ Voor 6% gewijzigd door ddv op 28-12-2004 15:07 ]

[_JGC_]

je weet dat bij NFS op uidNumber level gekeken wordt? Je moet dus zorgen dat je met de uidNumber op je client dingen kunt doen op de server. Verder vertel je er niet bij wat je precies als welke user doet, maar standaard wordt er user squashing toegevoegd waarbij root naar nobody wordt gemapt. Dit kan je uitzetten met no_root_squash in je export opties.

[TrailBlazer]

het lijkt erop dat 1 van die bestanden andere rechten heeft ofzo als je het een voor een doet. het lijtk me geen rechten probleem dat je de share niet mag benaderen

[ddv]

_JGC_ schreef op dinsdag 28 december 2004 @ 15:20:
je weet dat bij NFS op uidNumber level gekeken wordt? Je moet dus zorgen dat je met de uidNumber op je client dingen kunt doen op de server. Verder vertel je er niet bij wat je precies als welke user doet, maar standaard wordt er user squashing toegevoegd waarbij root naar nobody wordt gemapt. Dit kan je uitzetten met no_root_squash in je export opties.

Ik heb al een aantal squash opties uitgeprobeerd. Met root of zonder root op de client heeft ook geen effect gehad. Lijkt mij trouwens dat men geen no_root_squash wil gebruiken?

[ddv]

Ik heb het bestandssysteem nu op een andere manier gemount. Nu kan ik wel gewoon schrijven naar de share. Blijkbaar was het bestandsyssteem read-only gemount.

Dit bood de oplossing:

code:

mount -t ext3 -w /dev/md0 /mnt/raid

[ddv]

Helaas worden de problemen als maar erger. Ik ben er achter gekomen dat de kernel op de server /dev/md0 naar read-only mount.

Het volgende stond in /var/log/kernel/current:

EXT3-fs error (device md0): ext3_new_block: Allocating block in system zone - block = 23592966
ext3_abort called.
EXT3-fs error (device md0): ext3_journal_start_sb: Detected aborted journal.

Als ik nou vervolgens reboot begint fsck te klagen. Na fsck /dev/md0 te hebben gedaan op de console. Overigens kan ik niets anders vinden over sd of hd devices in /var/log. Zou er een schijf kapot zijn (heb ze 2 maanden geleden gekocht) Of zou de elcheapo controller kapot zijn? Of een misconfiguratie in de kernel? Help!

[ Voor 6% gewijzigd door ddv op 28-12-2004 18:42 ]

[ddv]

Ik heb deze problemen ook als ik elke schijf afzonderlijk partitioneer, filesystem en mount. Niemand die weet wat ik hier mee aan moet?

[Spider.007]

Lijkt erop dat er idd of op het FS; of fysiek op de hdd iets niet goed gaat:

quote: http://sourceforge.net/ma...d_id=417914&forum_id=6379

It means your block bitmap is corrupt and it says that metadata blocks are not in use, when they really are. That will lead to serious corruption.

Zie ook [google=ext3_new_block: Allocating block in system zone]

[ddv]

Spider.007 schreef op woensdag 29 december 2004 @ 13:29:
Lijkt erop dat er idd of op het FS; of fysiek op de hdd iets niet goed gaat:
[...]


Zie ook [google=ext3_new_block: Allocating block in system zone]

Wat zou er fysiek niet aan die schijf goed kunnen zijn? Ik heb ze pas geleden gekocht/gebruikt. Ik kan niet direct een antwoord vinden met behulp van verschillende searchengines.

[ddv]

Interessant detail is dat dit niet gebeurd bij EXT2.

[Verwijderd]

smartctl al geprobeerd?