Inappropriate ioctl for device after Ventura

Bug
#1

Please describe what you are doing to trigger the bug:
I believe this started after upgrading an Intel Mac to Ventura (13). I have a pretty simple backup that goes to an external flash drive, which is then copied to a remote location (OneDrive). I’m using the Web UI.

Please describe what you expect to happen (but doesn’t):
I expect the backup to succeed.

Please describe what actually happens (the wrong behaviour):
The backup fails with this error in the log:

2022-12-08 18:52:20.700 ERROR UPLOAD_CHUNK Failed to upload the chunk 5fafd9017a4902ed9f179366075dd7e2d75025e2c5b9a45e2935272ca272220c: sync /Volumes/RED FLASH/Mac Duplicacy Backup Data/chunks/5f/afd9017a4902ed9f179366075dd7e2d75025e2c5b9a45e2935272ca272220c.npjyplpv.tmp: inappropriate ioctl for device
Failed to upload the chunk 5fafd9017a4902ed9f179366075dd7e2d75025e2c5b9a45e2935272ca272220c: sync /Volumes/RED FLASH/Mac Duplicacy Backup Data/chunks/5f/afd9017a4902ed9f179366075dd7e2d75025e2c5b9a45e2935272ca272220c.npjyplpv.tmp: inappropriate ioctl for device

The check command is able to succeed, so it seems like Duplicacy can read the drive and all of the data is fine, but it can’t write.

I did fsck on the disk and it had no problems.

“Duplicacy Web Edition” has Full Disk Access; I also tried adding the duplicacy CLI but that didn’t help.

#2

Does it happen with every file or just one specific one? What filesystem is on the flash drive? How did you run fsck? Instead of fsck use (diskutil verifyVolume). Did it work before and suddenly stop, or never worked before?

(As an aside – full disk access does not matter for this, and you can only grant full disk access to app bundles, not CLI executables).

Who is the owner of that file? Are there any extended attributes on the directory or file? what user is duplicacy running as? Does duplciacy have write access to the disk? Is this a USB flash drive?

The above notwithstanding, if you are using exFAT – please don’t. In this case, you may be hitting this: backend/local: Ignore ENOTTY for fsync on Mac by greatroar · Pull Request #4021 · restic/restic · GitHub. @gchen would need to do something similar to backend/local: Ignore ENOTTY for fsync on Mac by greatroar · Pull Request #4021 · restic/restic · GitHub

However please, please, don’t store backups on exFAT volume.

In your case, duplciacy can directly backup to OneDrive, using exFAT in the middle you are only introducing instability into you backup workflow.

#3

Thanks for the reply saspus.

It seems to be on every file (chunk). Here’s from running it again, where it got the error on a different file. It’s also always the first file it tries to upload, after loading the exclusion filters:

2022-12-09 06:04:34.048 ERROR UPLOAD_CHUNK Failed to upload the chunk b613598cf8c8fd41d38b67ad2d43d674956280286b2815b92121cd1aa8f383f5: sync /Volumes/RED FLASH/Mac Duplicacy Backup Data/chunks/b6/13598cf8c8fd41d38b67ad2d43d674956280286b2815b92121cd1aa8f383f5.rckeicfu.tmp: inappropriate ioctl for device
Failed to upload the chunk b613598cf8c8fd41d38b67ad2d43d674956280286b2815b92121cd1aa8f383f5: sync /Volumes/RED FLASH/Mac Duplicacy Backup Data/chunks/b6/13598cf8c8fd41d38b67ad2d43d674956280286b2815b92121cd1aa8f383f5.rckeicfu.tmp: inappropriate ioctl for device

I had run the “First Aid” option in Disk Utility (the GUI), which runs fsck (and maybe other things?). I now just ran diskutil verifyVolume and it found no problems.

The backup had been working fine since January; I typically run it once a week. It only started having this problem this month. I don’t remember the exact timing, but I think it was after upgrading to Ventura, which is why I was suspicious of that.

Here’s the permissions on the file mentioned in the above log (Miriam is the user on the computer):

-rwx------  1 Miriam  staff  180114 Dec  9 06:04 /Volumes/RED FLASH/Mac Duplicacy Backup Data/chunks/b6/13598cf8c8fd41d38b67ad2d43d674956280286b2815b92121cd1aa8f383f5.rckeicfu.tmp

There doesn’t seem to be any extended attributes on that file. Duplicacy is also running as Miriam. Duplicacy should have write access to the disk. It is a USB flash drive.

The disk is FAT32.

I like the idea of having a local backup and a remote backup, so backing up to the flash drive and then copying that over to OneDrive seems reasonable to me. It’s also been working for the last year with no problems until now. The only thing that has changed is upgrading to Ventura; I haven’t changed any Duplicacy settings.

#4

There is your problem, it sounds like exactly the thing that @saspus referred to above. macOS started to do some weird things with FAT volumes, and it doesn’t look like this is something that you can correct on your end. Either Apple reverts macOS behavior to where it used to be (sounds unlikely), or software like :d: needs to introduce some code changes to work around that.

Unless, of course, you switch you backup setup to avoid FAT volumes.

#5

That’s unfortunate that Apple would change how they handle FAT volumes :frowning:. Given how old FAT32 is, you’d think they’d leave that code alone.

If I were to copy the Duplicacy Data folder from the flash drive somewhere temporarily, reformat the flash drive using APFS, and then copy the folder back over, would Duplicacy be happy with that? Or would it not realize those are the same files for that backup?

#6

I did not dig into this, but it appears that fsync on exFAT (and fat32) now returns ENOTTY, I.e not implemented or not supported. Was it always not supported but now started returning an error, or it returning an error now is a regression I’m not sure. This would be the question to apple developer relations.

Either way, needing to do sync after every chunk write is another manifestation of inadequacy of FAT32 for this purpose. It’s an ancient filesystem. It has a lot of issues and is not suitable for modern usecases. Stop using it.

Or JHFS+

Yes

Why would that be the case? Duplicacy operates above filesystem level. It does not care where and how files are stored as long as they can be read, written, and enumerated.

#7

I’ve dealt with programs before that did some funny things with metadata and/or disks, where you couldn’t simply do that. Glad to see that Duplicacy doesn’t care about that.

Anyway, thanks - that worked!

It took a very very long time to copy the files back onto the Flash Drive, but I ran a check and Duplicacy was happy with it; and the backup succeeds now!

#8

I see what you mean. Yes, duplicacy supports a variety of backends, including network and HTTPS destination, so it cannot depend on that by necessity. You can search the forum for “IEEE paper”, you’ll find a publication about duplicacy architecture and design, it’s a good read.

Is this a USB thumb drive, or USB connected mSATA or NVMe drive? If the former – those are horrific in terms of data retention. You will lose data. The latter write at 500-700 MB/sec, so that would not have been a long copy… I’m really concerned, that you might be exposing your data to unnecessary risk by using a thumb drive. It would be slightly better now that you don’t use FAT. It that likes to keep overwriting the same sectors over and over, (the actual FAT), and conventional thumb drives don’t manage wear leveling very well or at all.

#9

Thanks for the tip about thumb drives. I did some googling, and you’re right. While using one is certainly better than having no backup at all, they’re not as safe as I thought they were.

I’ve now moved the backup to an external hard drive (which already has HFS+).