SarahAS2

Hello all, I've just messed up a drive swap and I'm really, really close to losing data. First things first, the vital statistics: Unraid v6.11.5, running on... Dell PowerEdge R720xd 2x parity drives, 10x data drives, 2x cache drives - all formatted as BTRFS - controlled by... PERC H310 Mini, Firmware version 20.13.3-0001. Exposing the drives in JBOD mode, of course. Diagnostics are attached The drive I tried to swap, Disk 6, is dedicated to the share that holds my Time Machine backups, and similarly that share is pinned to Disk 6. So what did I do to get into this mess? I needed to remove what I'm going to call drive 6A, so I stopped the array and removed it. I thought it would be out for a while, so I replaced it with an identically-sized drive I'm going to call 6B. I assigned drive 6B to the array, then started the array. The emulated contents of Disk 6 were correct, and they were eventually rebuilt onto drive 6B. All was well for a time. After a while drive 6A became available again. Because it's a better drive than 6B, I decided to swap it back in. I stopped the array, removed 6B, and put 6A back in. Then things started to go a bit wrong. When I went back to restart the array Disk 6 showed as having no filesystem (though I'd never wiped it - it should have had all the same data on it as when it was removed). Although the option to format it was available, I did not do so - the warning message when you tick the format checkbox was quite clear that it wasn't what should be done. Although I found it a little bit odd that this hadn't happened with the earlier disk swap, I assumed from what I know of Unraid that the rebuild would of course rebuild the file system, so I started the array and allowed the rebuild to go on. Here's where I made my second mistake: I didn't check the emulated contents of Disk 6. While the rebuild was ongoing Time Machine kept failing to do its backups. I thought it was just being fussy about its storage (as it can be sometimes) and it would sort itself out once the rebuild was complete. In hindsight, this should also have tipped me off that all was not well on Disk 6 and I should have checked its emulated contents. Then, this evening, the rebuild finished. I ran Time Machine and it still failed. I went and had a look in Unraid, and Disk 6 was still showing as unmountable with no or wrong file system. I looked on both /mnt/user/Time\ Machine and /mnt/disk6. In both places the data was completely gone; the only thing remaining was the share directory. So, what do I do now? The server's sitting there with the array stopped. I presume there's no hope of recovering the data from within Unraid, but I do still have drive 6B. I haven't checked yet, but it should still have the data from Disk 6. Is the best course of action to just format 6A then rsync the data from 6B back onto the array? Finally, it's much less pressing, but I'd also like to know what I did wrong, and how I should have done it so I don't make this mistake again. Thank you in advance for all of your help.

Hello. Thanks for providing this most useful plugin, itimpi! Unfortunately I ran into a small problem with it when I last restarted my Unraid server. When this plugin's installed (specifically, version 2022.12.05 on Unraid version 6.11.5), the root of the filesystem gets its permissions set to 777. This causes OpenSSH to refuse to allow login with public/private key pairs with the error message "Authentication refused: bad ownership or modes for directory /" because it's worried about some other user nefariously providing extra "authorised" keys. If I uninstall the plugin and restart, / is back to 755 which satisfies OpenSSH. The workaround, of course, is to manually set the permissions of / after start up, but it would be better if this plugin could avoid changing them in the first place.

To slightly clarify wgstarks' point: you're not going to restore from backup. Your files, settings and so on will stay exactly where they are and a fresh copy of the operating system will be installed around them. If you wish, you can choose to wipe your whole disk (and thus need to restore from backups), but you'd need to actively select that option.

Hi all. I'm trying to install CIOPFS on Unraid. I downloaded the .txz from here and put it into /boot/extra. It seemed to load quite happily on restart, but whenever I try to use it, I get the error message "ciopfs: error while loading shared libraries: libulockmgr.so.1: cannot open shared object file: No such file or directory". It seems to be having a problem finding some library, but I'm not sure what. CIOPFS declares no dependencies, and when I tried to add the FUSE 3 package from here, Unraid declined to install it because it already had a later version (as I understand it, Unraid uses it to provide /mnt/user). Can anyone see what I'm doing wrong? Is the Unraid install of FUSE somehow tailored to do only what Unread needs it to do and unsuitable for adding other file systems on? unraid-diagnostics-20221126-1635.zip

Your wish is my command. 🙂 I'm hesitant since Docker's pretty new to me, so it's most likely I'm just using it wrong. I've listed the oddities I've found in the write up, though. I'd be interested to hear what more-experienced users like you think of them, or indeed if you run into them yourself when setting up for your Mac Pro.

So, as it seems no-one had converted this container to use AFP yet (or they're just keeping quiet about it 😉) here's how I did it after many attempts and equally many failures to get Time Machine working over SMB. There were a couple of non-obvious points (at least to a Docker and Unraid newbie like me). Many thanks are of course due to mbentley for the original container and moritzf for bringing it to Unraid; any problems you encounter with these instructions are undoubtedly down to errors or omissions on my part. Carefully read, understand, and accept the caveats that apply to the AFP tag in the "Image Tags" section of the Docker Hub page. In short: AFP is deprecated by Apple; the AFP tag is infrequently updated, less stable, will not receive new features, and may contain unpatched security vulnerabilities. Go and give the SMB version one last go. It's much better. Only use AFP if you've no other option. Edit the Time Machine Docker container. Switch to "advanced view" in the top right. We'll need some of those options Change the value in the "Repository" field to "mbentley/timemachine:afp" In the "Extra Parameters" field add " --ulimit nofile=65536:65536" after the --hostname parameter that should already be there. This will allow Docker (and hence Netatalk) to request more file descriptors than it has by default. Keep the custom network; it'll allow the service to be advertised by Avahi. Remove the following unnecessary parameters: "Size Limit", "Advertised Hostname", "Use Custom SMB Configuration", "Debug Level", "External Configuration Directory", "Hide Shares", "SMB Inherit Permissions", "SMB fruit:nfs_aces", "SMB fruit:metadata", "SMB Port", "SMB vfs objects", and "SMB Workgroup Name". (You don't strictly need to do this, but it will keep things tidy and prevent confusion later on.) The remaining ten parameters have the same semantics as they do in the SMB version. Set them or leave the default values as you see fit. Add the following Variables: CUSTOM_AFP_CONF, CUSTOM_USER, LOG_LEVEL, and VOLUME_SIZE_LIMIT. Descriptions and default values can be seen by expanding the "AFP Examples and Variables" section at the bottom of the Docker Hub page. All but VOLUME_SIZE_LIMIT can be left to default. N.B.: VOLUME_SIZE_LIMIT is different from the identically-named SMB incarnation. You cannot specify a unit; only the number of mebibytes (MiB) you want to set as a limit. The Docker should run and you should be able to select it in Time Machine preferences. The oddities I have found: To see what Netatalk's up to in detail, you have to open a console and tail or otherwise look in /var/log/supervisor/netatalk.log . I'm not experienced enough with Docker to say whether these messages being excluded from the easily-available logs is a feature, bug, or (most likely) a misconfiguration on my part. I seem to get "afpd[1511] {quota.c:646} (info:AFPDaemon): getquota: special /opt/[$TM_USERNAME] fails" entries in the Netatalk log at least once per backup. I don't know exactly what it means, but it doesn't seem to cause any problems. I don't know what the "right" number of file descriptors to assign to Netatalk is, how to find it out, or what the negative consequences (if any) of over-provision are. 65536 was the first suggestion I saw when Googling file descriptors in Unraid Docker, and seemed to work. Sometimes it just gets its knickers in a twist when it starts up and backups will fail with a message along the lines of "the selected device does not support the necessary operations". Simply restarting the container will usually cure it, although occasionally I've got it so fankled up it just won't exit. The only solution I've found is to SSH into the host and do a docker kill --signal=9 on it. I haven't been able to pin these cases down to a cause yet, but it seems to be a startup thing: once the first backup begins you can be reasonably confident in it lasting for a few days at least.

So, I finally got this (mostly) working, then ended up with COVID before I got around to writing it up. I tried changing the formatting of the underlying disks. This did nothing, probably meaning Unraid abstracts away a sensible amount of the underlying file system. What got it working for me was using the AFP branch of the Time Machine Docker container. There were a couple of non-obvious things (at least to a Docker newbie like me), so I'll probably write it up over at its support thread. It's not 100% stable and sometimes gets itself into a silly mode where it has to be kill -9ed, but what do you expect from deprecated software?

No change for me from re-installing 12.5.1, unfortunately. I have a couple of other ideas, but they need quite a lot of bits shuffled around before I can try them. Very possibly. The most frustrating thing from my point of view is that the NAS I'm trying to migrate from, a Drobo, is still happily Time Machining away over AFP despite Apple having deprecated the protocol.

I'm skeptical since I coincidentally re-installed the system a few weeks ago, but the 12.5.1 update has just been proffered to me and it won't be much more effort to reinstall so I'll give it a try. I'm absolutely open to the Docker, but I can't get it to work either. The symptoms are exactly the same: 'failed to attach'; 'operation not supported by device'. 😕

So, seemingly just to taunt me, Time Machine managed to do a second back up to the Unraid SMB share yesterday morning, but hasn't done another since. I don't know what was different or how I can bring it about again. >.< unraid-diagnostics-20220818-1039.zip

Has anyone successfully converted this container to use the afp tag? I tried but although it seemed to start up netatalk, I wasn't able to connect to it: it kept rejecting the username and password I'd set up.

Thanks, but I've tried that already to no avail.

unraid-diagnostics-20220812-0756.zip

Hello all, I'm currently trying out Unraid 6.10.3 on a Dell PowerEdge R720xd. Almost everything's going great, especially once I find the forum threads made by people who've had the same problems as me! Unfortunately, there's one big problem that I've found plenty of forum threads about, but for which I'm yet to find a working solution: Time Machine backups. I'm trying to use Time Machine to back up a single iMac running v12.5 "Monterey". I've tried both with the Time Machine Docker container (as updated on the 11th - today) and with Unraid's built-in SMB/Time Machine support, both with and without the SMB extra config very helpfully suggested here by wgstarks. Whatever setup I'm using, I've been unable to continue my old backups copied from the NAS I'm looking to replace. If I start a new backup (which I'd prefer not to do, but will resign myself to if it works), I've never been able to get any backups beyond the initial backup. Even the initial backup has struggled at times; it seems to get rather sensitive when the image gets bigger than about 800GB and does odd things like suddenly stopping when the mover runs, even if it's only running on another share. The problem always seems to be as shown in this extract from the backupd logs: default 21:54:41.071259+0100 backupd +[BackendXPC newFileBackendWithURL:fileOpenFlags:error:]: Image file stat: dev(0x3600005c), inode(1314760957312219803), mode(40775), uid(0), gid(0), size(16384), blocks(32) default 21:54:41.143327+0100 backupd -[DIAttachParams newAttachWithError:]: entry: DIAttachParams[DiskImageParamsLocked_XPC[SparseBundleBackendXPC]] default 21:54:41.143368+0100 backupd -[DIBaseXPCHandler createConnection]: Creating connection with com.apple.diskimagescontroller default 21:54:41.143543+0100 backupd +[DIEncryptionFrontend hasGUIaccess]: User session flags: 0x1 (0x1=root, 0x10=graphics, 0x20=hasTTY, 0x1000=IsRemote), secRes=0 default 21:54:41.359494+0100 backupd -[DIAttachParams reOpenIfWritableWithError:]: isWritableFormat: YES default 21:54:41.359543+0100 backupd +[BackendXPC newFileBackendWithURL:fileOpenFlags:error:]: Image file stat: dev(0x3600005c), inode(1314760957312219803), mode(40775), uid(0), gid(0), size(16384), blocks(32) default 21:54:41.769937+0100 backupd -[DIAttachParams reOpenIfWritableWithError:]: Image file <private> re-opened with RW permissions default 21:54:41.770010+0100 backupd -[DIStatFS logWithHeader:]: Input underlying FS: mounted on <private>, 1024 bytes block size, remote mount error 21:55:18.629965+0100 backupd -[DIBaseXPCHandler completeCommandWithError:]: Got error from last XPC command: Error Domain=NSPOSIXErrorDomain Code=19 "Operation not supported by device" UserInfo={DIErrorVerboseInfo=Failed to initialize IO manager: Failed opening folder for entries reading} error 21:55:18.630089+0100 backupd Failed to attach using DiskImages2 to url '/Volumes/.timemachine/timemachine._smb._tcp.local./DB7EB74C-1836-4DB5-B64D-55BBB02461E2/TimeMachine/iMac.sparsebundle', error: Error Domain=NSPOSIXErrorDomain Code=19 "Operation not supported by device" UserInfo={DIErrorVerboseInfo=Failed to initialize IO manager: Failed opening folder for entries reading} error 21:55:18.649180+0100 backupd Failed to unmount '/Volumes/.timemachine/timemachine._smb._tcp.local./DB7EB74C-1836-4DB5-B64D-55BBB02461E2/TimeMachine', Disk Management error: { Action = Unmount; Target = "file:///Volumes/.timemachine/timemachine._smb._tcp.local./DB7EB74C-1836-4DB5-B64D-55BBB02461E2/TimeMachine/"; } error 21:55:18.649617+0100 backupd Failed to unmount '/Volumes/.timemachine/timemachine._smb._tcp.local./DB7EB74C-1836-4DB5-B64D-55BBB02461E2/TimeMachine', error: Error Domain=com.apple.diskmanagement Code=0 "No error" UserInfo={NSDebugDescription=No error, NSLocalizedDescription=No Error.} error 21:55:19.764936+0100 backupd Failed to unmount '/Volumes/.timemachine/timemachine._smb._tcp.local./DB7EB74C-1836-4DB5-B64D-55BBB02461E2/TimeMachine', Disk Management error: { Action = Unmount; Target = "file:///Volumes/.timemachine/timemachine._smb._tcp.local./DB7EB74C-1836-4DB5-B64D-55BBB02461E2/TimeMachine/"; } error 21:55:19.765384+0100 backupd Failed to unmount '/Volumes/.timemachine/timemachine._smb._tcp.local./DB7EB74C-1836-4DB5-B64D-55BBB02461E2/TimeMachine', error: Error Domain=com.apple.diskmanagement Code=0 "No error" UserInfo={NSDebugDescription=No error, NSLocalizedDescription=No Error.} (for the record, this was using the Docker, attempting to make the second backup into a new image, but it seems to be substantively the same for other configurations) The actual problem seems to be the second error line (I think all the others are just knock on effects): Failed to attach using DiskImages2 to url '/Volumes/.timemachine/timemachine._smb._tcp.local./DB7EB74C-1836-4DB5-B64D-55BBB02461E2/TimeMachine/iMac.sparsebundle', error: Error Domain=NSPOSIXErrorDomain Code=19 "Operation not supported by device" UserInfo={DIErrorVerboseInfo=Failed to initialize IO manager: Failed opening folder for entries reading} Does anyone know which operation is not supported? What device is it referring to? The Unraid server? The SMB implementation? The disk image? Or just the mount point? I don't believe the disk image has been corrupted: it can be manually mounted in Finder/with Disk Utility. I've tried with cache set to both yes and no for the share, I've tried pinning the share to its own disk before creating the backup, I've tried the built in Time Machine support both with and without the mentions SMB extra configuration, and I've tried with the Docker container. Can anyone make any suggestions for either possible solutions or further diagnostics that will better pin down the problem?