unburt

On further reflection, it is possible the [conflicted] files were created sometime in the past and were not created by my current `mv` command. But, when I returned I saw the DSC_7862 [conflicted].NEF file in the source and the DSC_7862.NEF file in the destination and I did not see a [conflicted] version of the file in the destination, I tried the `mv * ../../disk1/files/` command a second time and it returned immediately and gave me the same output about being unable to remove directories due to them not being empty. So it seems like the mv command had no files to move and was aware of the [conflicted] files? I have since used Midnight Commander to complete the move and it had no issues about putting the DSC_7862 [conflicted].NEF file next to the DSC_7862.NEF file in the destination. So, perhaps there is a subtle difference?

Oh, I had no idea they would do things differently, I am familiar with "mc", so I can use that from now on. Is there somewhere I can read about how moving with "mc" differs from moving with "mv"? And should there be additional caveats on this wiki article? It suggests Midnight Commander as the first option but then says you can do the same thing with the usual "mv" without much mention of any danger aside from having your session end mid-move (and suggests nohup to mitigate this; in my case, I used tmux). https://wiki.unraid.net/Transferring_Files_Within_the_unRAID_Server

Hello, I attempted to move some files from one disk to another using the `mv` command and `/mnt/diskX` style paths. My working directory was `/mnt/disk5/files` and my command was: `mv * ../../disk1/files/` `mv` did not move everything and when I checked the source directory I found some files with names like `DSC_7862 [conflicted].NEF`. I was wondering if anyone knew where the `[conflicted]` part of the name came from? I did find that the destination directory already contained a file of the same name so it seems reasonable. I don't think I lost any data. I'm just curious how this works under the covers. Thanks! edit: I did have some output when I returned after mv had completed. Perhaps it might shed some light, but it seems that it was just reporting that it could not clean up the folders in the source location because some files had remained. This command was run from a tmux session so that I could leave it running for hours. root@Tower:/mnt/disk5/files# mv * ../../disk1/files/ mv: inter-device move failed: "My Permanent Files" to "../../disk1/files/My Permanent Files"; unable to remove target: Directory not empty mv: inter-device move failed: 'Photos' to '../../disk1/files/Photos'; unable to remove target: Directory not empty mv: inter-device move failed: 'e' to '../../disk1/files/e'; unable to remove target: Directory not empty mv: inter-device move failed: 'i' to '../../disk1/files/i'; unable to remove target: Directory not empty

I have resolved my issue by following the Restore From Backup article from the manual with the backup I created prior to updating to 6.10.3. I used the USB Creator on OSX with my backup zip file. https://wiki.unraid.net/Manual/Changing_The_Flash_Device I did still have to remove vfio-pci.cfg from the restored files though. And I had to run the make bootable batch file but otherwise I seem to be back up and running. it is frustrating not really knowing what actually went wrong but I guess that is the beauty of having a backup. it doesn't really matter.

If it is relevant, I believe a parity check may have been in progress.

In the syslog, I've found that there are a large number of errors with `nmbd`, this seems to be related to samba? What might be the problem here or what steps could I take to resolve it? Sep 8 18:25:05 Tower avahi-daemon[2162]: Server startup complete. Host name is Tower.local. Local service cookie is 1101267073. Sep 8 18:25:06 Tower avahi-daemon[2162]: Service "Tower" (/services/ssh.service) successfully established. Sep 8 18:25:06 Tower avahi-daemon[2162]: Service "Tower" (/services/smb.service) successfully established. Sep 8 18:25:06 Tower avahi-daemon[2162]: Service "Tower" (/services/sftp-ssh.service) successfully established. Sep 8 18:25:27 Tower nmbd[2132]: [2022/09/08 18:25:27.246828, 0] ../../source3/nmbd/nmbd_become_lmb.c:398(become_local_master_stage2) Sep 8 18:25:27 Tower nmbd[2132]: ***** Sep 8 18:25:27 Tower nmbd[2132]: Sep 8 18:25:27 Tower nmbd[2132]: Samba name server TOWER is now a local master browser for workgroup WORKGROUP on subnet 192.168.1.152 Sep 8 18:25:27 Tower nmbd[2132]: Sep 8 18:25:27 Tower nmbd[2132]: ***** Sep 8 18:25:27 Tower nmbd[2132]: [2022/09/08 18:25:27.462024, 0] ../../source3/libsmb/nmblib.c:923(send_udp) Sep 8 18:25:27 Tower nmbd[2132]: Packet send failed to 192.168.1.52(137) ERRNO=Destination address required Sep 8 18:25:27 Tower nmbd[2132]: [2022/09/08 18:25:27.462096, 0] ../../source3/nmbd/nmbd_packets.c:1027(reply_netbios_packet) Sep 8 18:25:27 Tower nmbd[2132]: reply_netbios_packet: send_packet to IP 192.168.1.52 port 137 failed Sep 8 18:25:27 Tower nmbd[2132]: [2022/09/08 18:25:27.462161, 0] ../../source3/libsmb/nmblib.c:923(send_udp) Sep 8 18:25:27 Tower nmbd[2132]: Packet send failed to 192.168.1.52(137) ERRNO=Destination address required Sep 8 18:25:27 Tower nmbd[2132]: [2022/09/08 18:25:27.462181, 0] ../../source3/nmbd/nmbd_packets.c:1027(reply_netbios_packet) Sep 8 18:25:27 Tower nmbd[2132]: reply_netbios_packet: send_packet to IP 192.168.1.52 port 137 failed Sep 8 18:25:46 Tower login: pam_unix(login:session): session opened for user root(uid=0) by LOGIN(uid=0) Sep 8 18:25:46 Tower login: ROOT LOGIN ON tty1 Sep 8 18:27:37 Tower nmbd[2132]: [2022/09/08 18:27:37.710253, 0] ../../source3/libsmb/nmblib.c:923(send_udp) Sep 8 18:27:37 Tower nmbd[2132]: Packet send failed to 192.168.1.52(137) ERRNO=Destination address required Sep 8 18:27:37 Tower nmbd[2132]: [2022/09/08 18:27:37.710313, 0] ../../source3/nmbd/nmbd_packets.c:1027(reply_netbios_packet) Sep 8 18:27:37 Tower nmbd[2132]: reply_netbios_packet: send_packet to IP 192.168.1.52 port 137 failed Sep 8 18:27:37 Tower nmbd[2132]: [2022/09/08 18:27:37.710371, 0] ../../source3/libsmb/nmblib.c:923(send_udp) Sep 8 18:27:37 Tower nmbd[2132]: Packet send failed to 192.168.1.52(137) ERRNO=Destination address required Sep 8 18:27:37 Tower nmbd[2132]: [2022/09/08 18:27:37.710388, 0] ../../source3/nmbd/nmbd_packets.c:1027(reply_netbios_packet) Sep 8 18:27:37 Tower nmbd[2132]: reply_netbios_packet: send_packet to IP 192.168.1.52 port 137 failed Sep 8 18:27:37 Tower nmbd[2132]: [2022/09/08 18:27:37.710432, 0] ../../source3/libsmb/nmblib.c:923(send_udp) Sep 8 18:27:37 Tower nmbd[2132]: Packet send failed to 192.168.1.52(137) ERRNO=Destination address required Sep 8 18:27:37 Tower nmbd[2132]: [2022/09/08 18:27:37.710449, 0] ../../source3/nmbd/nmbd_packets.c:1027(reply_netbios_packet) Sep 8 18:27:37 Tower nmbd[2132]: reply_netbios_packet: send_packet to IP 192.168.1.52 port 137 failed Sep 8 18:27:37 Tower nmbd[2132]: [2022/09/08 18:27:37.710486, 0] ../../source3/libsmb/nmblib.c:923(send_udp) Sep 8 18:27:37 Tower nmbd[2132]: Packet send failed to 192.168.1.52(137) ERRNO=Destination address required Sep 8 18:27:37 Tower nmbd[2132]: [2022/09/08 18:27:37.710501, 0] ../../source3/nmbd/nmbd_packets.c:1027(reply_netbios_packet) Sep 8 18:27:37 Tower nmbd[2132]: reply_netbios_packet: send_packet to IP 192.168.1.52 port 137 failed Sep 8 18:30:28 Tower nmbd[2132]: [2022/09/08 18:30:28.907945, 0] ../../source3/libsmb/nmblib.c:923(send_udp) Sep 8 18:30:28 Tower nmbd[2132]: Packet send failed to 192.168.1.52(137) ERRNO=Destination address required

In another topic I learned about the `diagnostics` command to create the diagnostics zip file. I have attached it here. tower-diagnostics-20220908-1907.zip

Hi, I have been using Unraid for several years. Last night I updated from 6.10.2 to 6.10.3 and all seemed well. This morning I tried to set up a VPN tunnel. I had some issue where the server stopped responding so I powered it off. After power on, I was unable to reach the Web UI. Since I do not have a graphics card in the server, I powered it off again, installed a graphics card and attached a monitor to see the screen output. It was stuck in booting and I googled the last few output lines and found some suggested resolutions to delete vfio-pci.cfg from my USB (I did attempt passing through a GPU in the past and was not successful). I deleted the file and the system now boots and reaches the prompt and allows me to log in. However, I still cannot reach the web UI. Do you have any suggestions on troubleshooting from this point? I have checked the network cable, it is still attached. I unplugged it and rebooted Unraid, after it boots it shows that it has no ip address. After reconnecting the network cable, and rebooting Unraid, it shows its IP address. <edit> I forgot to describe some of the mucking around that I did: 1. Last night, I had made a backup of my USB on version 6.10.2 prior to updating. 2. After I experienced issues, I used a macbook and used dd to create a disk image of my USB (presumably on 6.10.3) 3. I have copied the contents of my 6.10.2 backup onto the flash drive. 4. I have since mounted the dd image on my macbook and copied the contents of the disk image onto the flash drive I am currently in a state where I can log in to the console but I cannot reach the web ui. </edit>

I'm trying to preclear a disk but it has encountered an error claiming the disk is part of the array. I am fairly certain the disk is not part of the array and it is the error that is wrong. Perhaps it has to do with the disk being assigned the name sda? I have 1 parity disk (sdae), 5 array disks (sdab, sdac, sdai, sadh, sdag), and 34 unassigned devices (sda through sdan excluding the previously listed names). I have the Unassigned Devices and Unassigned Devices Plus plugins installed if that makes a difference. In the "preview" window, it does not list any potential candidates for preclearing which seems odd to me. Is there some kind of workaround I can employ? tower-diagnostics-20211201-1416.zip

Thanks. What does the icon in the bottom right do?

Is it possible to use fotosho to delete images?

Thanks for the advice. I think only Removed dockers will show up in Previous Apps? In any case, it wasn't there so I removed the docker and then reinstalled it from CA. I guess the most important thing was to relocate the /appdata/ for the application since that is where all of its state is stored between shutdowns and luckily I could guess my other config settings since there weren't many. Thanks for telling me about "Allow 2nd instance"!

I am running the youtube-dl-material docker (tzahi12345/youtubedl-material) and then I was in the Add Container page and selected it as the template because I wanted a second installation of it. I filled in some information and then I clicked the 'X' icon at the top of the page next to the Template field and clicked yes on the Are You Sure popup. I thought it would just clear my information from this page but, it deleted the template entirely. Oops. Now, when I go to my existing youtube-dl-material docker and click Edit, it brings me to the Update Container page but it has no information populated. It doesn't even have a name. What do I do now? If I search in community apps for youtube-dl-material, it just links me back to the same blank edit page since it knows I already have it installed. How can I check what the config should look like?

You make a great point about the workloads that can be expected from the drive that I have. I promise I endeavoured to use it in a very light-duty way (probably contravening some other NAS/unraid principles though). I intended to exclude it from other shares and to write 8TB of seldom accessed files to it now and never touch it again. Basically, I could have kept it as an external drive but it seemed "cleaner" to me to get it inside my PC case rather than having the enclosure sit on a nearby shelf. Perhaps having it as a mounted unassigned disk would be an improvement so that it would not be included in monthly parity checks. ps. I really appreciate your citations. With your comments + reading the cited articles, it was much easier for me to understand them.

Oh right. Good point.