Jeremy Allison schreef op 30-04-2016 1:06:>> Copying a file to my mounted samba share did not work, the files are >> created by they remain at 0 size. Then apparently smbd blocks in IO >> and never continues, never recovers. I cannot kill the process, I >> will have to reboot the NAS but it won't unmount filesystems so I >> need a hard reset. > > That sounds like a kernel bug. Samba only uses normal > open/pread/pwrite/ > close calls which should work on top of truecrypt as far as I know.Before I had issues on some device using TrueCrypt because the entire thing would hang (mostly SMBD, then) when I read or actually wrote files to a truecrypt volume mounted inside of another filesystem, so that smbd would have to cross a filesystem boundary. I never tested what would happen if the share itself was in the mounted crypt, from the beginning. I now compiled LUKS on the device and I get an even stranger error in a certain sense. From the "top level" samba share, the subdirectory that has LUKS mounted, doesn't show any files. However, when I create another share directly on the mounted LUKS subfolder, the files are there. So the transition from regular filespace to LUKS filespaces (different volume) is not getting this LUKS filespace to appear empty to Samba, but not to the linux system itself. Is this to be expected? Is that normal operation, this? Regards. ps. it is not a great problem because the intent is probably going to be to share an entire crypt container anyway, so the problem wouldn't surface, I just wonder whether it is normal.
On Fri, Jul 01, 2016 at 12:18:11PM +0200, Xen wrote:> Jeremy Allison schreef op 30-04-2016 1:06: > > >>Copying a file to my mounted samba share did not work, the files are > >>created by they remain at 0 size. Then apparently smbd blocks in IO > >>and never continues, never recovers. I cannot kill the process, I > >>will have to reboot the NAS but it won't unmount filesystems so I > >>need a hard reset. > > > >That sounds like a kernel bug. Samba only uses normal > >open/pread/pwrite/ > >close calls which should work on top of truecrypt as far as I know. > > > > Before I had issues on some device using TrueCrypt because the > entire thing would hang (mostly SMBD, then) when I read or actually > wrote files to a truecrypt volume mounted inside of another > filesystem, so that smbd would have to cross a filesystem boundary. > > I never tested what would happen if the share itself was in the > mounted crypt, from the beginning. > > I now compiled LUKS on the device and I get an even stranger error > in a certain sense. > > From the "top level" samba share, the subdirectory that has LUKS > mounted, doesn't show any files. > > However, when I create another share directly on the mounted LUKS > subfolder, the files are there. > > So the transition from regular filespace to LUKS filespaces > (different volume) is not getting this LUKS filespace to appear > empty to Samba, but not to the linux system itself. Is this to be > expected? > > Is that normal operation, this?Hard to tell without logs I'm afraid. We'd need much more data to tell, but the honest answer is probably "don't do that" :-).
Jeremy Allison schreef op 01-07-2016 19:53:>> So the transition from regular filespace to LUKS filespaces >> (different volume) is not getting this LUKS filespace to appear >> empty to Samba, but not to the linux system itself. Is this to be >> expected? >> >> Is that normal operation, this? > > Hard to tell without logs I'm afraid. We'd need much more data > to tell, but the honest answer is probably "don't do that" :-).I have no other smbd logs other than output that says that some parameter (wide symlinks) is unknown. There is nothing else in there. The previous error (with Truecrypt) was found in some logs though. Basically umount is trying to kill the process, but it is unkillable: Apr 30 00:35:50 diskstation umount: Kill the process "/usr/syno/sbin/smbd" with /store/home/xen. Apr 30 00:35:50 diskstation umount: Kill the process "/usr/syno/sbin/smbd" with /store/home/xen. Apr 30 00:35:50 diskstation umount: Kill the process "/usr/syno/sbin/smbd" with /store/home/xen. Apr 30 00:35:50 diskstation umount: Kill the process "/usr/syno/sbin/smbd" with /store/home/xen. Apr 30 00:35:50 diskstation umount: Kill the process "/usr/syno/sbin/smbd" with /store/home/xen. Apr 30 00:35:50 diskstation umount: Kill the process "/usr/syno/sbin/smbd" with /store/home/xen. Apr 30 00:35:50 diskstation umount: Kill the process "/usr/syno/sbin/smbd" with /store/home/xen. Apr 30 00:35:50 diskstation umount: Kill the process "/usr/syno/sbin/smbd" with /store/home/xen. The unkillable machine ;-). Anyway, this makes it troublesome because I want only a small area of my share to be encrypted ;-). The thing is both data storage (personal files) and a workspace (for when I log into the machine). So basically I need "two" homedirectories..... This is annoying and compicates matters. I have found a solution but now my system hangs. The most annoying thing about samba (and applies to NFS as well) as a client, is that when there is some network error; the entire system may hang as all reads of the root filesystem (or the / directory) can block until that network mount thing is resolved, practically rendering your entire system frozen. Is there not a solution for that?