June 3, 20215 yr I think the issue is that my user share(s) failed to mount, then some other process keep filling the /mnt/user/'same name with shared drive' directory with files supposed to be in the Shared drive but it just filling up my rootfs. root@Tower:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 16G 16G 124K 100% / devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm cgroup_root 8.0M 0 8.0M 0% /sys/fs/cgroup tmpfs 128M 1.0M 127M 1% /var/log /dev/sda1 30G 251M 30G 1% /boot overlay 16G 16G 124K 100% /lib/modules overlay 16G 16G 124K 100% /lib/firmware /dev/md1 13T 13T 505G 97% /mnt/disk1 /dev/md2 15T 15T 222G 99% /mnt/disk2 /dev/md3 15T 15T 276G 99% /mnt/disk3 /dev/md4 13T 3.6M 13T 1% /mnt/disk4 /dev/md5 15T 3.6M 15T 1% /mnt/disk5 It's almost like the move is still working on the background, but I did multiple reboot and removed both of the cache drive. only thing I noticed in the syslog is this SIGTERM during boot: Jun 3 15:51:15 Tower emhttpd: Starting services... Jun 3 15:51:15 Tower emhttpd: shcmd (123): chmod 0777 '/mnt/user/Farming' Jun 3 15:51:15 Tower emhttpd: shcmd (124): chown 'nobody':'users' '/mnt/user/Farming' Jun 3 15:51:15 Tower emhttpd: shcmd (126): /etc/rc.d/rc.samba restart Jun 3 15:51:15 Tower nmbd[2280]: [2021/06/03 15:51:15.423181, 0] ../../source3/nmbd/nmbd.c:59(terminate) Jun 3 15:51:15 Tower winbindd[2290]: [2021/06/03 15:51:15.423181, 0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler) Jun 3 15:51:15 Tower nmbd[2280]: Got SIGTERM: going down... Jun 3 15:51:15 Tower winbindd[2292]: [2021/06/03 15:51:15.423184, 0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler) Jun 3 15:51:15 Tower winbindd[2290]: Got sig[15] terminate (is_parent=1) Jun 3 15:51:15 Tower winbindd[2292]: Got sig[15] terminate (is_parent=0) Jun 3 15:51:15 Tower winbindd[2339]: [2021/06/03 15:51:15.423243, 0] ../../source3/winbindd/winbindd.c:244(winbindd_sig_term_handler) Jun 3 15:51:15 Tower winbindd[2339]: Got sig[15] terminate (is_parent=0) Jun 3 15:51:17 Tower root: Starting Samba: /usr/sbin/smbd -D Jun 3 15:51:17 Tower root: /usr/sbin/nmbd -D Jun 3 15:51:17 Tower smbd[2968]: [2021/06/03 15:51:17.560346, 0] ../../lib/util/become_daemon.c:135(daemon_ready) Jun 3 15:51:17 Tower smbd[2968]: daemon_ready: daemon 'smbd' finished starting up and ready to serve connections tower-diagnostics-20210603-1551.zip Edited June 3, 20215 yr by pliu Attached diagnostic file
June 3, 20215 yr @pliu, your diagnostics might provide more details. Go to Tools / Diagnostics and attach the zip to your next post. You might already know this but linux is case sensitive (unlike Windows), are you sure your path are taking this into account ?
June 3, 20215 yr Author 54 minutes ago, ChatNoir said: @pliu, your diagnostics might provide more details. Go to Tools / Diagnostics and attach the zip to your next post. You might already know this but linux is case sensitive (unlike Windows), are you sure your path are taking this into account ? @ChatNoir sorry, I don't know what you mean by 'your path are taking this into account', I am just stating the fact that my rootfs are keep filing up for a strange reason, probably due to the share disappeared, but I don't know what process is writing the content of the disks (which are part of the shared drive) into the wrong shared drive mount point, and keep filling it up.
June 3, 20215 yr 46 minutes ago, pliu said: @ChatNoir sorry, I don't know what you mean by 'your path are taking this into account', I am just stating the fact that my rootfs are keep filing up for a strange reason, probably due to the share disappeared, but I don't know what process is writing the content of the disks (which are part of the shared drive) into the wrong shared drive mount point, and keep filling it up. Are you sure that the path are 100% good, including upper/lower case ? If you attempt to write to a path that does not correspond to a proper path, Unraid will write to rootfs, possibly filling it.
June 3, 20215 yr Author 7 minutes ago, ChatNoir said: Are you sure that the path are 100% good, including upper/lower case ? If you attempt to write to a path that does not correspond to a proper path, Unraid will write to rootfs, possibly filling it. Which path? I don't think I've change any config to do with path, what I did last night was play with cache settings (enabled the cache with the user share), stated the mover and realized that the move is actually moving the data from the user share to the cache (I though the mover is to move data from cache to the user share as I am uploading data via SFTP to the user share which write automatically to the cache and the cache just keep filling up). anyway, I just don't know which path name I might be fat fingered...
June 3, 20215 yr Author I think I've solved the issue, but still don't know exactly what happed I finally realized that I have another machine upload files to the user share, which used to be fill the cache, but since I stopped the cache last night, something might be getting confused somewhere. So the ftp keep uploading to the user share, but for some reason, user share was not there anymore, so it just automatically uploading the data to the rootfs. To get back my user share, I did two things: 1. I deleted the user share which is the same name, but was the wrong one (it will write data to rootfs instead of my physical disks. 2. I uninstalled the unassigned plugin. and after done those two things, I reboot the unraid server, and I got my correct user share back (with the same name as the one on the rootfs). I am guessing that it might be that my disks spin down, and the user share goes down with it, but unraid created a substitute user share using rootfs, and I am keeping thing that's my old user share, and SFTP keep uploading files to in once I manually freed it up. Sounds crazy? tell me about it! Edited June 3, 20215 yr by pliu Wording
June 3, 20215 yr I got a similar error - I got Camers which uploads Pictures and Videos to one share. If I restart Unraid, all my Shares are gone, Docker and VM Service won't start. The try of my camera to upload to the share, blocked unraid for booting correct. I don't know why it is, because I use Unraid since 2 years and the camera exactly this way since day one. If I stop the FTP Upload of the Camera and boot Unraid, it's starting fine with all the Shares and services.
June 5, 20215 yr Author On 6/4/2021 at 2:42 AM, Pete_Stonehiller said: I got a similar error - I got Camers which uploads Pictures and Videos to one share. If I restart Unraid, all my Shares are gone, Docker and VM Service won't start. The try of my camera to upload to the share, blocked unraid for booting correct. I don't know why it is, because I use Unraid since 2 years and the camera exactly this way since day one. If I stop the FTP Upload of the Camera and boot Unraid, it's starting fine with all the Shares and services. In my case, the upload fills up the rootfs, so if you do the 'df -h' it will shows rootfs is full, so it might be that your upload is filling up the rootfs?
June 5, 20215 yr 15 hours ago, pliu said: In my case, the upload fills up the rootfs, so if you do the 'df -h' it will shows rootfs is full, so it might be that your upload is filling up the rootfs? I don't know. I could test it, if I have to restart the server again. How could I test it? Start the Array, go to terminal and write "df -h" ?
June 5, 20215 yr Community Expert The usual reason for a docker to fill rootfs is specifying a container path that doesn't correspond to actual storage (a subfolder of /mnt). @pliu Are you sure you aren't doing ftp directly to /mnt and not one of the mounted subfolders in /mnt? The user shares are subfolders of /mnt/user, for example, and not subfolders at the top level of /mnt. The user shares are /mnt/user/<name-of-share> The disks are /mnt/cache, /mnt/<some-other-named-pool>, /mnt/disk1, /mnt/disk2,... The Unassigned Disks are /mnt/disks/<mount-name-you-specify> The Unassigned Remotes are /mnt/remotes/<mount-name-you-specify> You should not be writing anything directly into /mnt, but only use an already existing subfolder in /mnt. And you should not be writing into any other path not in /mnt.
June 6, 20215 yr Author 7 hours ago, trurl said: The usual reason for a docker to fill rootfs is specifying a container path that doesn't correspond to actual storage (a subfolder of /mnt). @pliu Are you sure you aren't doing ftp directly to /mnt and not one of the mounted subfolders in /mnt? The user shares are subfolders of /mnt/user, for example, and not subfolders at the top level of /mnt. The user shares are /mnt/user/<name-of-share> The disks are /mnt/cache, /mnt/<some-other-named-pool>, /mnt/disk1, /mnt/disk2,... The Unassigned Disks are /mnt/disks/<mount-name-you-specify> The Unassigned Remotes are /mnt/remotes/<mount-name-you-specify> You should not be writing anything directly into /mnt, but only use an already existing subfolder in /mnt. And you should not be writing into any other path not in /mnt. The path for the upload is right as I have to go to the '/mnt/user/my shared path' to actually delete the files to free up my rootfs.
June 6, 20215 yr Community Expert 5 minutes ago, pliu said: The path for the upload is right as I have to go to the '/mnt/user/my shared path' to actually delete the files to free up my rootfs. Is the array actually started when transfer to that path?
June 6, 20215 yr Author 8 hours ago, Pete_Stonehiller said: I don't know. I could test it, if I have to restart the server again. How could I test it? Start the Array, go to terminal and write "df -h" ? yes, that should do it, but I am using ssh to the Unraid server for the command line stuff. But think again, I don't think your case is same as mine as if your rootfs is filled up which stopped the Array, then simply stop the ftp wouldn't do it as I have to also delete files to free up the rootfs to get Array working.
June 6, 20215 yr Author 6 minutes ago, trurl said: Is the array actually started when transfer to that path? Good point, I started the upload overnight. And it's probably stopped during the night, as I saw the overwrite confirmation dialog in FileZilla (as it discovered same files from the source to the destination). I think the array was not been able to proper started in my initial restart, then after I delete the files uploaded to rootfs, the array was started successfully, then probably stopped working after it's been filled up as all the disks shows in the unassigned mount point. But I do know that the array was started after I freed up the rootfs as I am having problem stop the Array after a while (when the rootfs filled up).
Archived
This topic is now archived and is closed to further replies.