madgino Posted January 31 Share Posted January 31 I have lost all my shares and unable to start docker or the VM Manager. I've restarted multiple times, but it looks like the /mnt/user/system/docker/ and /mnt/user/appdata are not mapped to my physical drives Please refer to the attached diagnositc dump, is anyone help to give me some direction. This was in the process of creating some VM's and installing the Intel-GPU-TOP package. Everything was working fine, until I performed a reboot. tower-diagnostics-20240201-0421.zip tower-diagnostics-20240201-0353.zip tower-diagnostics-20240201-0309.zip Quote Link to comment
trurl Posted January 31 Share Posted January 31 Your syslog is full of these Feb 1 04:21:24 Tower sshd[8610]: Starting session: command for root from 10.60.0.11 port 59130 id 1 Feb 1 04:21:24 Tower sshd[8610]: Close session: user root from 10.60.0.11 port 59130 id 1 Any idea what that is about? That IP isn't on the same network as your server. Your user shares aren't being mounted. Instead, we see this before they have a chance to mount: Feb 1 04:12:30 Tower emhttpd: shcmd (50): chmod 0777 '/mnt/user/mattbackup' Feb 1 04:12:30 Tower emhttpd: shcmd (51): chown 'nobody':'users' '/mnt/user/mattbackup' Any idea what that is about? Quote Link to comment
madgino Posted January 31 Author Share Posted January 31 A mate had a rysnc docker container setup to connect to his debian box and do a backup. We have a VPN between each other, it's his IP. I can shutdown the tunnel if that would help, but I doubt it - sorry that the logs are full of that error message. Quote Link to comment
trurl Posted January 31 Share Posted January 31 And is that /mnt/user/mattbackup also related to the rsync? That is what is breaking your user shares since they haven't had a chance to be mounted yet. Quote Link to comment
madgino Posted January 31 Author Share Posted January 31 Yeah that share was created for his back up using Rsync, this is not something that was implemented recently though. Quote Link to comment
trurl Posted January 31 Share Posted January 31 1 minute ago, madgino said: Yeah that share was created for his back up using Rsync How exactly was it created? Why it it being accessed before it exists? Quote Link to comment
madgino Posted January 31 Author Share Posted January 31 Sorry Trul, I'll only know that when he wakes up - It's 6AM - sorry to waste your time. I'm trying to work out how it was created. Quote Link to comment
trurl Posted January 31 Share Posted January 31 Just make another post when you want me to see this thread again. Quote Link to comment
itimpi Posted January 31 Share Posted January 31 8 minutes ago, madgino said: Yeah that share was created for his back up using Rsync, this is not something that was implemented recently though. The key point is that he must not try to do the rsync until Unraid has successfully started up (in particular its User Share system). Perhaps in the past you were just lucky with the timing? Quote Link to comment
madgino Posted February 1 Author Share Posted February 1 Thank you both very much for pointing me in the right direction. You were right, it was timing related. Rebooting my server while the overnight backup was running meant the directory was created before unraid had finished booting. After deleting the directory and rebooting my user share came back, and I was able to restore my docker containers by reinstalling them from "Previous Apps" My friend has now adjusted his backup script to only run if the directory already exists. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.