StevenHB

I've installed cups 2.2.7 as a Docker app on my unraid server and had to do some work to get it to start. It now works great, sort-of, enabling access to my networked but not airprint-enabled printers from my Android and my wife's iOS phone . . . until the unraid server reboots. I'm sure that the docker is storing the printer config information somewhere that's not persistent across reboots, but I have no idea how to fix this. Can anyone help? I know that I'm missing some technical knowledge that would enable me to fix this.

Can you (or anyone else here) tell me what community FTP application you use, please?

Thanks for all of your help. It took a couple of orders but I've now received my replacement drive and a SATA->IDE converter (it turned out that I needed to replace an IDE drive with an IDE drive in the box I'm using). I ended up with an extra 3T of storage. In any case, I replaced the failed drive with a new 250M IDE drive which rebuilt without issue (in v5.0.5). I then re-upgraded to v6.1.3, copying super.dat as suggested. Worked like a charm. I'm preclearing the new 3T drive and will swap it for one of two older 250M drives, so that in the end, I'll have a hot spare for the oldest drive in the array. I've come into a newer motherboard, so I may look at upgrading the processor hardware next, but I'd like to get the new storage online before I start screwing with the motherboard. Thanks again.

Yeah, thanks. I'm not probably not going to need to use it for the next few days. Your warning is well-taken.

Is there something more that I should do now, or just wait for my new drive, rebuild, and re-upgrade?

Yes, it was presented on the console. Displayed as a notification on the v6 console (in the upper right hand corner, black text on a green background) Thanks, I will. However, in this situation, I was generally finding the console to be unresponsive. I tried clicking on Tools but continued to get indefinite hourglassing. The drive indicator (the one that's usually a green dot) is red and "Not Installed" is displayed in italics on the unraid main screen. Overall, my experience has been that v6 performed much slower than v5 (which was even more noticeable after I reverted). Thanks for the pointer about the re-upgrade.

I recently upgraded to v6. My server worked okay for a while (about a week) but I've had issues lately. I had an error on a data disk (" No device identification present"). I shutdown the server and unplugged it. After rebooting, the problematic drive "returned to normal operations" but I'm now having trouble restarting the array. I reassigned the drive to the array and clicked "start," which left the array unstarted, drives unmounted, and the control panel hour-glassing indefinitely. I copied off the v6 log file and have zipped and attached it here. I've since reverted to v5.05 which has indicated an error with the drive but started without issue. I'm wondering if there's some problem with failed drive handing in v6. (for the record, I've ordered a replacement drive that I'll install next week) Can anyone help me figure out what happened with v6? And once I get the new drive cleared, installed, and rebuilt, can I just restore by v6 backup, run make_bootable, and be on my way? syslog-20151030.zip

Thank you both for the quick response. I'm sorry that I overlooked those items while upgrading.

So I've upgraded to 6.1.3. My server is up and the array is online. I'm noticing a few omissions: make - the makefile utility isn't installed screen - also isn't installed I'd like to use screen to run preclear from the command line. Is there a reason that I don't need screen anymore? It's running in a live terminal session, but I recognize that it could fail at any time. I tried installing it as an extra, but I'm now getting an "screen: error while loading shared libraries: libutempter.so.0: cannot open shared object file: No such file or directory." I'm not sure how to install the so. Can you help?

I've now had FTP work successfully two days in a row, so I'm prepared to conclude that there's something about using the share from my Windows client that's causing the problem. I still have a mapped drive to Disk1. It's not being used for anything, but I'll change it to use the multi-disk share and, eventually, will switch back to using the share for backups to see if it makes a difference. I have a decent workaround in the meantime.

I think that I have a drive on that laptop mapped to one of the drives. I can eliminate it. There's definitely content that was stored on Disk1 which is now part of the new, combined share. Is this a problem by itself? What additional setup information would you like?

I'm consistently getting errors writing to the unraid system I maintain in my home. I first noticed this when the Duplicati backup process that uses the unraid system for its storage would fail with an error message such as this one: Failed after uploading 192 volume(s). Error message: Failed to upload file "duplicati-inc-content.20150907T052251Z.vol193.zip": The process cannot access the file '\\<IP address>\<path>\Duplicati\duplicati-inc-content.20150907T052251Z.vol193.zip' because it is being used by another process. While working with it yesterday, I found that files I edited locally (from my Windows 8.1 laptop) couldn't be written back - attempts would get a similar message about the file being in use by a another process. Now that I think about it, this could be related to the use of a multi-disk share that I recently setup and started using. Is there a known problem with multi-disk shares? For what it's worth, the work I was doing yesterday was to switch to using FTP (vsftpd) to send files to the unraid server. The backup that ran overnight did not get any "used by another process" errors (I'd been getting them consistently before that change), so that may be another clue as to where the issue lies.

Someone asked for the preclear reports from the IDE drive. I've attached them. preclear_start__No_Information_Found_2012-03-12.txt preclear_finish__No_Information_Found_2012-03-12.txt preclear_finish__No_Information_Found_2012-03-12.txt

Joe, it turns out that the hard drive was already connected to the last (end) connector of an 80-conductor ribbon cable, as it was supposed to be, so that's not it. Any other thoughts?

Thanks, Joe, that could be. It's a pretty old box - circa 2005. I'm not at home but I'll take a look at that.