Ubuntu 20.04 Chia blockchain Copy operation not permitted

[nielsgeode]

Mijn vraag
Waarom krijg ik bij het plotten met Chia blockchain files in de laatste stap deze foutmelding en hoe los ik dit op?

Could not copy /mnt/tempdrive/tempfile to /mnt/finaldrive/finalfile. Error Operation not permitted.

Relevante software en hardware die ik gebruik
Ubuntu 20.04 x64 op een X470 Master SLI met Ryzen 9 x3900. Ik maak ("plot") de files op temporary disks en kopieer ze daarna naar een 14 TB NTFS volume.
Reden: als de schijf vol is wil ik deze in windows zonder speciale truckjes kunnen lezen.

Wat ik al gevonden of geprobeerd heb
Het klinkt als een chmod probleem en veel meer kan ik op het internet niet vinden. Wat ik geprobeerd heb en niet werkt zijn:

sudo chmod -R 0777 /mnt/finaldrive
en
sudo chown -R niels:niels /mnt/finaldrive

[thunder7]

Het zou ook kunnen dat je een file probeert te kopieren met een naam die op NTFS niet toegestaan is, bijvoorbeeld.

[nielsgeode]

thunder7 schreef op woensdag 12 mei 2021 @ 18:03:
Het zou ook kunnen dat je een file probeert te kopieren met een naam die op NTFS niet toegestaan is, bijvoorbeeld.

De filenames bevatten alleen maar hoofdletters, kleine letters en getallen. Als ik handmatig in een terminal een normale cp doe (zonder sudo) werkt het prima.

[thunder7]

Wat is dan exact de laatste stap? Je link verwijst naar allerlei algemene info, maar wat is exact de stap waarbij het mis gaat?

[nielsgeode]

thunder7 schreef op woensdag 12 mei 2021 @ 18:32:
Wat is dan exact de laatste stap? Je link verwijst naar allerlei algemene info, maar wat is exact de stap waarbij het mis gaat?

Op je temp drive wordt flink geschreven, bestanden gemaakt, weggegooid etc. Aan het einde van dat hele proces maakt de software eerst een temp file aan die al wel helemaal af is. Vervolgens wordt die temp file gewoon gekopieerd (en hernoemd van .plot.2.tmp naar .plot) naar de final dir.

Die kopieeractie geeft in de log van de Chiasoftware de genoemde foutmelding. Als ik dan een terminal open zie ik dus die 101.x GiB .plot.2.tmp file staan. Die kopieer ik handmatig en hernoem ik naar .plot. De software pakt de file dan als een goeie plot, alleen dit is niet handmatig bij te houden. Je wilt dat ie kopieert, opschoont en een nieuwe start.

Idee: als ik het volume converteer naar exFAT dan zijn je rechten geen issue meer toch?

Toevoeging: ik heb nog een ander systeem ook draaien en daar werkt het wel gewoon onder Ubuntu 20.04.

[ Voor 9% gewijzigd door nielsgeode op 12-05-2021 18:43 ]

[thunder7]

Ik zou inderdaad eens een ander filesystem proberen om dat uit te sluiten.

[nielsgeode]

thunder7 schreef op donderdag 13 mei 2021 @ 06:45:
Ik zou inderdaad eens een ander filesystem proberen om dat uit te sluiten.

Als de schijven vol zijn gaan ze uiteindelijk terug naar windows 10 en dan denk dat NTFS wel het beste bestandssysteem is. Het moet gewoon werken, op mijn andere systeem werkt het wel gewoon onder linux.

Gisteren dacht ik de oorzaak gevonden te hebben: in fstab heb ik voor de partitie umask=007 aangepast naar umask=000. Daarna een umount en mount gedaan, maar dat werkt niet. Of moet je daarvoor rebooten / daemon restarten, want dat kon nog niet omdat ie bezig is en er geen resume-optie bestaat.

[Hero of Time]

Als je non-native filesystems gaat mounten in Linux, moet je bij de mount opties nog wel even de eigenaar en eventueel groep bij opgeven, anders is het standaard alleen te beschrijven door root. En afhankelijk van de staat van het filesystem wordt het ook nog eens read-only. Zeker als je met een NTFS filesystem werkt waar een actieve Windows installatie tegenover staat. Want Windows sluit niet meer af, die gaat in semi-hibernate, dus het filesystem zal ten alle tijden als 'dirty' worden gemarkeerd en dan mag je niets schrijven.

Wil je iets dat 'gewoon werkt', neem dan FAT of een externe schijf die je fatsoenlijk afkoppelt.

[nielsgeode]

Hero of Time schreef op zondag 16 mei 2021 @ 11:29:
Als je non-native filesystems gaat mounten in Linux, moet je bij de mount opties nog wel even de eigenaar en eventueel groep bij opgeven, anders is het standaard alleen te beschrijven door root. En afhankelijk van de staat van het filesystem wordt het ook nog eens read-only. Zeker als je met een NTFS filesystem werkt waar een actieve Windows installatie tegenover staat. Want Windows sluit niet meer af, die gaat in semi-hibernate, dus het filesystem zal ten alle tijden als 'dirty' worden gemarkeerd en dan mag je niets schrijven.

Wil je iets dat 'gewoon werkt', neem dan FAT of een externe schijf die je fatsoenlijk afkoppelt.

Uiteindelijk heb ik de oplossing gevonden. In fstab stond de 14tb met een iets andere syntax gemount. Dat heb ik niet zelf direct erin gezet, ik heb 'disks' gebruikt onder ubuntu. De andere NTFS schijven werkken / werkten wel gewoon. Ik heb de syntax handmatig in fstab aangepast en nu werkt het (eindelijk)

[Hero of Time]

Kan je nog de voor en na situatie van de opties geven? Want het is niet echt behulpzaam om te zeggen dat je 'iets' hebt aangepast zonder te specificeren wat dat precies is geweest.

[nielsgeode]

Hero of Time schreef op woensdag 19 mei 2021 @ 16:39:
Kan je nog de voor en na situatie van de opties geven? Want het is niet echt behulpzaam om te zeggen dat je 'iets' hebt aangepast zonder te specificeren wat dat precies is geweest.

Dat bedacht ik mij ook toen ik het had aangepast. "Had ik maar opgeschreven wat er stond." Maarja, toen was het "verkeerde" al weg en ik ben bepaald niet goed in het onthouden van syntax.

[Hero of Time]

Je kan op z'n minst posten wat het nu is. Want dat het werkt zal wel, maar of het ook het beste is en nog voor fatsoenlijke veiligheid zorgt is een ander punt.

[nielsgeode]

Hero of Time schreef op donderdag 20 mei 2021 @ 07:41:
Je kan op z'n minst posten wat het nu is. Want dat het werkt zal wel, maar of het ook het beste is en nog voor fatsoenlijke veiligheid zorgt is een ander punt.

Dit staat nu in fstab:

/dev/disk/by-uuid/5A4684144683EF57 /mnt/6tb_D auto nosuid,nodev,nofail,x-gvfs-show,noauto 0 0

[Hero of Time]

En nu kan je er als gewone gebruiker in schrijven, of alleen als root? Ik verwacht alleen als root als ik die opties zo zie.

[nielsgeode]

Hero of Time schreef op dinsdag 25 mei 2021 @ 16:51:
En nu kan je er als gewone gebruiker in schrijven, of alleen als root? Ik verwacht alleen als root als ik die opties zo zie.

De data heeft geen enkele beveiliging nodig, je kan er immers toch niks mee. Ik heb een

sudo chmod -R /mnt/partition

gedaan en nu kan een gewone gebruiker er ook schrijven.

Het gekke is dat eerst een gewone gebruiker in de terminal er ook al kon schrijven, maar de log files van chia wel 'operation not permitted' errors gaven.