Ok, I'm a little new to linux, and normally I wouldn't try and do something like this in an unfamiliar OS, but my sister has an old imac hard drive she wants pictures off of and my windows machine won't read her drive. Linux reads it fine. More than fine actually, but Garuda for some reason won't let me transfer it to a thumb drive. I keep getting an error that says "Could not make folder /run/media/filename/USB31FD/filename/Pictures/place ." I can make folders manually, but it won't make the folder in order to do the transfer. Also I can transfer all of the individual sub-folders one at a time, but I can't just send the whole containing folder.
I can transfer the whole folder to my Linux drive without problem. I am also able to transfer it to an extra hard drive without issue, but both of those drives are ext4 and windows/mac won't read it unless I format it; which would then destroy anything I put on it. I have tried fat32 and exfat (Since the file is significantly larger than 4 gigs). I have tried transferring with root options on right click, I have tried running as root. I have tried transferring with command line sudo and as root. Macs have trouble with NTFS and my sister is not computer savvy. Garuda simply will not allow me to transfer this 500gig file of pictures with all of its subfolders.
I have searched ddg for the error message and get nothing. I have looked through the forums on both Arch and Garuda and can't find any one who has had the same problem. Honestly, I was able to work around by transferring each sub-folder manually, so it's not a must-fix, but it was incredibly time consuming and tedious. I was wondering if there was something I'm missing, if there is some limit because of fat file systems I don't know about, or if this is a bug that needs to be worked out in Dolphin.
I believe the old drive is fat 32, but I had no problem transferring the photos off of the drive. They are on an ext4 drive now. The problem is that I need them back on a drive an iMac will read. So it needs to be exfat or fat32. NTFS doesn't play well with iMacs, nor do the varius versions of ext. You can probably get them to work, but my sister isn't tech savvy and I won't be there to do it for her; she lives too far away. I figured fat32's limits would be an issue, since it can't really do files larger than 4Gib, but exfat doesn't have that limitation and I was trying to put it on an exfat. I seem to be able to transfer files. I can even transfer folders full of files. I just can't transfer folders that are inside other folders. That alone makes me think it's the filing system, but I was able to transfer FROM a fat 32 drive to an ext4 with no real problem. So I was thinking it might be a bug in Dolphin. I was hoping there might be a setting I'm missing or a workaround. But it could also be that ext4 is just more broadly compatible than exfat. Someone already suggested compression and I'm working on that right now.
I tried that after posting. It doesn't seem to be file size that's an issue. If I transfer a folder that contains other folders, then it won't write some of the sub-folders and stops transferring before it gets to any of the sub-folder's contents and that's when it spits out the error. So it seems to do files just fine. It will even do a folder full of files, but if I send a folder full of folders it just quits. I am trying compression now. It's a large folder and will likely take hours to compress.
Exfat will work on Linux,mac,windows, but you have to format Exfat with windows or mac to get a really successful transfer you also need exfat-utilities installed on linux. This is what i have used for a couple of years, Unfortunately Linux can be the weak point with exfat. By the way the 4gb limit is for individual fat files so 100 3.9gb files is no problem
IIRC macs can read ext4 and other FSs, unlike Windows.
Each of those might have different error messages, that could help us identify the problem.
Check journal for those errors, or start dolphin from the terminal and log/post the error messages.
It is strange that you can copy one folder at a time, but not the parent folder with everything, so you should describe the sequence of your actual actions in more detail. For example, some bugs may have to do with DragAndDrop, others with clipboard, or the backend utility that is being used for the transfer.
Also, when posting exact terminal output, don’t use something so general as filename to replace a piece of text (probably user name). It would make it easier to focus and not try to assume whether this is some random filename, a user name, or something that might matter on troubleshooting.
And this reminded me an old support case with a user that had assigned names for $USER, hostname etc. words like failed, error, missing... etc., which made the effort to filter logs by failure error messages impossible!..
Also, as unlikely as it seems, the kernel could also be a factor. I have worked on more than one case where changing kernels resolved file transfer errors. While this is probably unlikely in your case, it would be worthwhile to install the LTS kernel regardless.
Thanks to everyone who helped. Compressing the file worked. I still don't know what the bigger issue is, but I imagine it has to do with the file system, or some other black magic that's beyond my pay grade.
and not try to assume whether this is some random filename, a user name, or something that might matter on troubleshooting.
