May 29, 200917 yr Hi Everyone, I've been a long time user, and finally got around to dealing with this issue: My flash drive disappears - or at least all the files on it do, after accessing it. The files are still there, and unraid still works, but I won't be able to access the flash without a reboot. I recently changed mother boards, but it happened with the old one as well. In fact I've always had the problem, but it's only become annoying since trying out new add ons. Attached is my syslog. Any help is appreciated. I suspect I may have to petition Tom for a replacement key for a new flash. I think things start to go sour here: May 28 19:10:28 Tower kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 2 May 28 19:10:28 Tower kernel: usb 1-3: device descriptor read/64, error -71 May 28 19:10:28 Tower kernel: usb 1-3: device descriptor read/64, error -71 May 28 19:10:28 Tower kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 2 May 28 19:10:28 Tower kernel: usb 1-3: device descriptor read/64, error -71 May 28 19:10:29 Tower kernel: usb 1-3: device descriptor read/64, error -71 May 28 19:10:29 Tower kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 2 May 28 19:10:29 Tower kernel: usb 1-3: device not accepting address 2, error -71 May 28 19:10:29 Tower kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 2 May 28 19:10:30 Tower kernel: usb 1-3: device not accepting address 2, error -71 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99447 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99511 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99535 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99543 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99559 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99639 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99647 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99655 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 190 May 28 19:10:30 Tower kernel: Buffer I/O error on device sde1, logical block 127 May 28 19:10:30 Tower kernel: lost page write due to I/O error on sde1 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 1166 May 28 19:10:30 Tower kernel: Buffer I/O error on device sde1, logical block 1103 May 28 19:10:30 Tower kernel: lost page write due to I/O error on sde1 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 2047 May 28 19:10:30 Tower kernel: Buffer I/O error on device sde1, logical block 1984 May 28 19:10:30 Tower kernel: lost page write due to I/O error on sde1 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99100 May 28 19:10:30 Tower kernel: Buffer I/O error on device sde1, logical block 99037 May 28 19:10:30 Tower kernel: lost page write due to I/O error on sde1 May 28 19:10:30 Tower kernel: Buffer I/O error on device sde1, logical block 99038 May 28 19:10:30 Tower kernel: lost page write due to I/O error on sde1 May 28 19:10:30 Tower kernel: Buffer I/O error on device sde1, logical block 99039 May 28 19:10:30 Tower kernel: lost page write due to I/O error on sde1 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 64 May 28 19:10:30 Tower kernel: Buffer I/O error on device sde1, logical block 1 May 28 19:10:30 Tower kernel: lost page write due to I/O error on sde1 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99663 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99679 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99695 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99703 May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Unhandled error code May 28 19:10:30 Tower kernel: sd 0:0:0:0: [sde] Result: hostbyte=0x07 driverbyte=0x00 May 28 19:10:30 Tower kernel: end_request: I/O error, dev sde, sector 99711 May 28 19:10:30 Tower kernel: usb 1-3: USB disconnect, address 2 May 28 19:10:30 Tower kernel: usb 1-3: new high speed USB device using ehci_hcd and address 3 May 28 19:10:30 Tower kernel: usb 1-3: device descriptor read/64, error -71 May 28 19:10:30 Tower kernel: usb 1-3: device descriptor read/64, error -71 May 28 19:10:31 Tower kernel: usb 1-3: new high speed USB device using ehci_hcd and address 4 May 28 19:10:31 Tower kernel: usb 1-3: device descriptor read/64, error -71 May 28 19:10:31 Tower kernel: usb 1-3: device descriptor read/64, error -71 May 28 19:10:31 Tower kernel: usb 1-3: new high speed USB device using ehci_hcd and address 5 May 28 19:10:32 Tower kernel: usb 1-3: device not accepting address 5, error -71 May 28 19:10:32 Tower kernel: usb 1-3: new high speed USB device using ehci_hcd and address 6 May 28 19:10:32 Tower kernel: usb 1-3: device not accepting address 6, error -71 May 28 19:10:32 Tower kernel: hub 1-0:1.0: unable to enumerate USB device on port 3 May 28 19:10:33 Tower kernel: usb 3-3: new full speed USB device using ohci_hcd and address 2 May 28 19:10:33 Tower kernel: usb 3-3: device descriptor read/64, error -62 May 28 19:10:33 Tower kernel: usb 3-3: device descriptor read/64, error -62 May 28 19:10:33 Tower kernel: usb 3-3: new full speed USB device using ohci_hcd and address 3 May 28 19:10:33 Tower kernel: usb 3-3: device descriptor read/64, error -62 May 28 19:10:34 Tower kernel: usb 3-3: device descriptor read/64, error -62 May 28 19:10:34 Tower kernel: usb 3-3: new full speed USB device using ohci_hcd and address 4 May 28 19:10:34 Tower kernel: usb 3-3: device not accepting address 4, error -62 May 28 19:10:34 Tower kernel: usb 3-3: new full speed USB device using ohci_hcd and address 5 May 28 19:10:35 Tower kernel: usb 3-3: device not accepting address 5, error -62 May 28 19:10:35 Tower kernel: hub 3-0:1.0: unable to enumerate USB device on port 3 May 28 19:10:41 Tower in.telnetd[1498]: connect from 192.168.1.7 (192.168.1.7) May 28 19:11:07 Tower login[1499]: ROOT LOGIN on `pts/0' from `192.168.1.7' May 28 19:11:16 Tower kernel: FAT: Directory bread(block 1984) failed May 28 19:11:16 Tower kernel: FAT: Directory bread(block 1985) failed May 28 19:11:16 Tower kernel: FAT: Directory bread(block 1986) failed May 28 19:11:16 Tower kernel: FAT: Directory bread(block 1987) failed May 28 19:11:16 Tower kernel: FAT: Directory bread(block 1988) failed May 28 19:11:16 Tower kernel: FAT: Directory bread(block 1989) failed May 28 19:11:16 Tower kernel: FAT: Directory bread(block 1990) failed May 28 19:11:16 Tower kernel: FAT: Directory bread(block 1991) failed May 28 19:11:19 Tower kernel: FAT: Directory bread(block 1984) failed May 28 19:11:19 Tower kernel: FAT: Directory bread(block 1985) failed May 28 19:11:19 Tower kernel: FAT: Directory bread(block 1986) failed May 28 19:11:19 Tower kernel: FAT: Directory bread(block 1987) failed
May 29, 200917 yr That's clearly unacceptable, and if it has done that on 2 different motherboards, then it is defective. You probably should have had that replaced a long time ago. See the FAQ, "If my flash drive dies or is lost, will I lose my license?" And when you email Tom, you might reference this thread.
June 4, 200917 yr Author It occurs to me since the flash isn't totally dead, I can do this: - Configure a new flash drive to boot unraid. It will be called something other then "UNRAID" - Leave the old flash drive connected, but non bootable. it will still be called "UNRAID" Then, Unraid will run from the new flash, and just use the old one for license check, even if the old one becomes unavailable it won't matter, because /boot will be mapped to the new good flash. Do you think this will work?
June 4, 200917 yr It occurs to me since the flash isn't totally dead, I can do this: - Configure a new flash drive to boot unraid. It will be called something other then "UNRAID" - Leave the old flash drive connected, but non bootable. it will still be called "UNRAID" Then, Unraid will run from the new flash, and just use the old one for license check, even if the old one becomes unavailable it won't matter, because /boot will be mapped to the new good flash. Do you think this will work? It might.... unRAID will still try to mount the old flash drive labeled UNRAID at /boot... That might cause you some issues. You might need to have your new drive mounted there first so it does not mount the one labeled "UNRAID" Remember, it looks for the license file in /boot/config/*.key. Joe L.
June 4, 200917 yr It occurs to me since the flash isn't totally dead, I can do this: - Configure a new flash drive to boot unraid. It will be called something other then "UNRAID" - Leave the old flash drive connected, but non bootable. it will still be called "UNRAID" Then, Unraid will run from the new flash, and just use the old one for license check, even if the old one becomes unavailable it won't matter, because /boot will be mapped to the new good flash. Do you think this will work? It might.... unRAID will still try to mount the old flash drive labeled UNRAID at /boot... That might cause you some issues. You might need to have your new drive mounted there first so it does not mount the one labeled "UNRAID" Remember, it looks for the license file in /boot/config/*.key. Joe L. I really wish this licensing mode changed. There has to be a way to tell the key is inserted. It should not matter if it is mounted or not. For example my GUID is 058F-6335-0000-058F011111B1 and in /proc/usb/bus/usb/devices there is the following information available. T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=058f ProdID=6335 Rev= 1.02 S: Manufacturer=Generic S: Product=Mass Storage Device S: SerialNumber=058F011111B1 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=250mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms and in root@unraid /tmp #find /dev -name '*058F011111B1*' /dev/disk/by-id/usb-SD.MMC_Card_Reader_058F011111B1-0:0-part2 /dev/disk/by-id/usb-SD.MMC_Card_Reader_058F011111B1-0:0-part1 /dev/disk/by-id/usb-SD.MMC_Card_Reader_058F011111B1-0:0 /dev/.udev/names/disk%2fby-id%2fusb-SD.MMC_Card_Reader_058F011111B1-0:0-part2 /dev/.udev/names/disk%2fby-id%2fusb-SD.MMC_Card_Reader_058F011111B1-0:0-part1 /dev/.udev/names/disk%2fby-id%2fusb-SD.MMC_Card_Reader_058F011111B1-0:0
June 4, 200917 yr It occurs to me since the flash isn't totally dead, I can do this: - Configure a new flash drive to boot unraid. It will be called something other then "UNRAID" - Leave the old flash drive connected, but non bootable. it will still be called "UNRAID" Then, Unraid will run from the new flash, and just use the old one for license check, even if the old one becomes unavailable it won't matter, because /boot will be mapped to the new good flash. Do you think this will work? It might.... unRAID will still try to mount the old flash drive labeled UNRAID at /boot... That might cause you some issues. You might need to have your new drive mounted there first so it does not mount the one labeled "UNRAID" Remember, it looks for the license file in /boot/config/*.key. Joe L. I really wish this licensing mode changed. There has to be a way to tell the key is inserted. It should not matter if it is mounted or not. For example my GUID is 058F-6335-0000-058F011111B1 and in /proc/usb/bus/usb/devices there is the following information available. T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=058f ProdID=6335 Rev= 1.02 S: Manufacturer=Generic S: Product=Mass Storage Device S: SerialNumber=058F011111B1 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=250mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms and in root@unraid /tmp #find /dev -name '*058F011111B1*' /dev/disk/by-id/usb-SD.MMC_Card_Reader_058F011111B1-0:0-part2 /dev/disk/by-id/usb-SD.MMC_Card_Reader_058F011111B1-0:0-part1 /dev/disk/by-id/usb-SD.MMC_Card_Reader_058F011111B1-0:0 /dev/.udev/names/disk%2fby-id%2fusb-SD.MMC_Card_Reader_058F011111B1-0:0-part2 /dev/.udev/names/disk%2fby-id%2fusb-SD.MMC_Card_Reader_058F011111B1-0:0-part1 /dev/.udev/names/disk%2fby-id%2fusb-SD.MMC_Card_Reader_058F011111B1-0:0 I'm going to guess that emhttp is probably using the information from /proc/usb/devices to get data to form the USB device key... but it is looking in /boot/config to find the .key file. Remember, the "found" .key file content is decrypted and then compared with the generated GUID. I don't think it is necessary to have the USB drive mounted at /boot, but the directory at /boot/config needs to have the affiliated key file. Furthermore, although it is very unusual, and most frequently an accident, I'm fairly certain it is possible to mount a file-system on a directory that is not empty. It might then be possible to do something like mount -t vfat /dev/other-usb-drive-partition /boot/config and completely replace the entire config folder with a different file-system holding the .key file, even if the USB drive was initially mounted at /boot. I did not say it would be easy... but I'm fairly sure I've read of people who use alternate boot devices and still have their .key file found and used. Joe L.
June 4, 200917 yr Author I'm going to guess that emhttp is probably using the information from /proc/usb/devices to get data to form the USB device key... but it is looking in /boot/config to find the .key file. Remember, the "found" .key file content is decrypted and then compared with the generated GUID. so if this is the case, then I call the drive that I'm booting off of UNRAID, which will have the key file, and the one that matches the key file can be called something else. The goal is the new flash mounted at /boot, but the key being checked against the old flash. This would also protect the licensed flash from wear. I'll get a new flash and try it.
June 5, 200917 yr Author No go on this scheme. It seems to check the GUID of the device that it mounted as boot.
June 5, 200917 yr No go on this scheme. It seems to check the GUID of the device that it mounted as boot. I would think it checks the GUID of the device labeled as UNRIAD, against the file it finds at /boot/config/*.key
June 7, 200917 yr Author What about this: boot from the licensed flash modify the go script to do the following instead of running emhttp mkdir /licflash mount --move /boot /licflash mount -t vfat /dev/sdf1 /boot /boot/go I'm not sure the best way to make sure I'm mounting the right flash, but as long as no drives are added, the dev shouldn't change. Think it would work?
June 7, 200917 yr Author OK, so I got this to work. The system boots from an unlicensed flash that is labeled FLASH. The UNRAID flash is mounted to /boot and the go script in /boot/config is run by standard unraid., This go script creates a new mount point, and mounts the stick labeled as FLASH , then runs a go script on it. The go script on FLASH moves what was mounted at /boot to another location, then mounts the stick labeled as FLASH at /boot. The rest of the go script is then standard. (starts emhttp, cache_dirs, unmenu) So I guess on the UNRAID stick, all I need is really /config/go the rest of it can be empty. so far seems to be ok
June 7, 200917 yr What about this: boot from the licensed flash modify the go script to do the following instead of running emhttp mkdir /licflash mount --move /boot /licflash mount -t vfat /dev/sdf1 /boot /boot/go I'm not sure the best way to make sure I'm mounting the right flash, but as long as no drives are added, the dev shouldn't change. Think it would work? If you have labeled the second drive as "FLASH" then you can probably mount the second "flash drive" with mkdir /licflash mount --move /boot /licflash mount -t vfat /dev/disk/by-label/FLASH /boot /boot/go If you do a "ls -l /dev/disk/by-label/FLASH" you'll see it is a link to the first partition of the flash drive. That way, the drive letter can change as you add drives... ( I know the drive letter does change on mine... especially if I plug in a USB hard-disk, or a second USB flash drive.) Joe L. (I learned something new from your post... I never knew of the --move option of mount... very useful, thanks...)
June 7, 200917 yr Oh yes, you might want to also add the following options to your "mount" of the new "FLASH" drive mount -o noatime,nodiratime,umask=0,shortname=mixed -t vfat /dev/disk/by-label/FLASH /boot At least that is how the normal unRAID flash drive is mounted. The noatime and nodiratime will keep the flashdrive from wearing out earlier than otherwise if files on it are accessed frequently. The others (umask and shortname) will not matter as much, but might make it easier when it is exported as a share. Joe L.
June 7, 200917 yr Author Thanks for the tips Joe: mount -t vfat /dev/disk/by-label/FLASH /boot I was able to figure this one out - figured there had to be a way. mount -o noatime,nodiratime,umask=0,shortname=mixed -t vfat /dev/disk/by-label/FLASH /boot At least that is how the normal unRAID flash drive is mounted. The noatime and nodiratime will keep the flashdrive from wearing out earlier than otherwise if files on it are accessed frequently. The others (umask and shortname) will not matter as much, but might make it easier when it is exported as a share. Yeah, I saw how that's how it normally mounted it - wasn't sure what the options were for. I'm going to make the change.
June 8, 200917 yr Author fervently following this and hoping for a wrap-up how-to at the end Ok, I'll do one tonight
June 9, 200917 yr Author OK, My goal was to use the flash that was linked to my license key only to validate the software, and to boot and store configuration on another flash drive. The reason to do this was my licensed flash drive is flakey. It works well enough to boot, and run stock unraid, but if it is accessed much, it's file system becomes unavailable. This made it difficult to use any of the add-ons that others have written. There may be a better way to accomplish this, but the following is what I did, and it seems to work. (things could be cleaned up as well) 1. Label the licensed flash (the one linked to your key file) "UNRAID" 2. make the /config/go script on this flash look like this: #!/bin/bash mkdir /licflash mkdir /flash mount -o noatime,nodiratime,umask=0,shortname=mixed -t vfat /dev/disk/by-label/FLASH /flash cd /flash/config /flash/config/go2 & 3. Prepare the second flash drive in the normal unraid method. Except label it "FLASH" 4. make the /config/go script on this flash look like this: #!/bin/bash # Start the Management Utility mount --move /boot /licflash mount -o noatime,nodiratime,umask=0,shortname=mixed -t vfat /dev/disk/by-label/FLASH /boot /usr/local/sbin/emhttp & /boot/cache_dirs -w /boot/unmenu/uu note the last 2 lines are only necessary if you are running those addons. Now, configure the server to boot from the second flash (actually it doesn't matter which one it boots from), and you'll end up with the FLASH drive mounted at /boot and /flash, and the UNRAID flash mounted at /licflash.
June 9, 200917 yr Brilliant... Does emhttp startup normally and start the full array? Does it detect the proper GUID?
June 9, 200917 yr Author Does emhttp startup normally and start the full array? Does it detect the proper GUID? Yes & Yes It all seems to be working correctly.
June 9, 200917 yr armbrust, In your example, the first script on the drive labeled "UNRAID" invokes "go2" yet the script on the drive labeled "FLASH" is still named "go" I'm pretty sure that the two file names must match... otherwise, nothing will be invoked and emhttp will not be started. Either you must name the script on the drive labeled "FLASH" as config/go2, or you must invoke it with /flash/config/go & Also, when you are done, nothing is mounted at /flash. You describe the drive labeled "FLASH" as being mounted there. It is not. It is mounted at /boot, and its "share" name on the LAN is \\tower\flash. You end up with the drive labeled "UNRAID" mounted at /licflash. That is as good a name as any. As you said, it does not need to be the boot drive, nor does it need anything other than the "config/go" script. Other than that... very nice work. Joe L.
June 9, 200917 yr Author Thanks Joe In your example, the first script on the drive labeled "UNRAID" invokes "go2" yet the script on the drive labeled "FLASH" is still named "go" Yes you are right, step 4 should read: 4. make the /config/go2 script on this flash look like this: Also, when you are done, nothing is mounted at /flash. You describe the drive labeled "FLASH" as being mounted there. It is not. It is mounted at /boot, and its "share" name on the LAN is \\tower\flash. It's actually mounted at both /boot and /flash. It gets mounted at /flash in the first go script. One of the things that could be cleaned up.
Archived
This topic is now archived and is closed to further replies.