vazagothic

New Members
  • Content count

    2
  • Joined

  • Last visited

Community Reputation

0 Neutral

About vazagothic

  • Rank
    Newbie
  1. Trial of Nanoboot (4493) - 5.0.3.1

    I don't really know a solution, but maybe a workaround.. Have you tried copy your files with ssh as root? cp /volume1/YOURFILE /volumeUSB2/share/YOURFILE maybe making a dmesg for more information dmesg > /volume1/FOLDER/dmesg.txt I can copy files onto /volumeUSB2/usbshare/ via SSH - there's no problem with it whatsoever. I think I'm onto something as I just tried doing the same thing on another computer and it worked without any problems. There may be an issue with credentials stored on my main computer as I was using it before the gnoBoot -> Nanoboot change. It's possible that Windows keeps some incorrect credentials and keeps on passing them onto the DSM and crashes Samba in the process. I'll try clearing up credentials on my Windows machine then report here if I fix it.
  2. Trial of Nanoboot (4493) - 5.0.3.1

    I'm experiencing problems copying files to the usbshare2 (from Windows) - a 4TB USB drive (NTFS) connected to the N54L server running DSM 5.0 Update 1 (via Nanoboot). Judging by the smdb.log file Samba unexpectedly dies. Copied file is created (it's blank though) but I can't access it w/o rebooting the server (file is locked). I didn't have this problem before while using gnoBoot. It's worth mentioning that while I can't COPY files to the usbshare2 I can still DOWNLOAD/RENAME/DELETE them w/o any issues. The issue occurs regardless of the path, filename and filesize, check_user_ok: user admin is an admin user. Setting uid as 0 smbd/service.c:1169: [2014/06/27 20:50:26.621706, all 1, pid=27664] make_connection_snum UMSPC (192.168.1.20) connect to service usbshare2 initially as user admin (uid=0, gid=100) (pid 27664) smbd/sesssetup.c:1417: [2014/06/27 20:50:26.622110, all 2, pid=27664] setup_new_vc_session setup_new_vc_session: New VC == 0, if NT4.x compatible we would close all old resources. smbd/vfs.c:1131: [2014/06/27 20:50:26.622980, vfs 3, pid=27664] check_reduced_name check_reduced_name [1234567890ABCDEFG01.txt] [/volumeUSB2/usbshare] smbd/vfs.c:1265: [2014/06/27 20:50:26.623097, vfs 3, pid=27664] check_reduced_name check_reduced_name: 1234567890ABCDEFG01.txt reduced to /volumeUSB2/usbshare/1234567890ABCDEFG01.txt smbd/vfs.c:1131: [2014/06/27 20:50:26.623669, vfs 3, pid=27664] check_reduced_name check_reduced_name [.] [/volumeUSB2/usbshare] smbd/vfs.c:1265: [2014/06/27 20:50:26.623766, vfs 3, pid=27664] check_reduced_name check_reduced_name: . reduced to /volumeUSB2/usbshare smbd/vfs.c:1131: [2014/06/27 20:50:26.647827, vfs 3, pid=27664] check_reduced_name check_reduced_name [.] [/volumeUSB2/usbshare] smbd/vfs.c:1265: [2014/06/27 20:50:26.647915, vfs 3, pid=27664] check_reduced_name check_reduced_name: . reduced to /volumeUSB2/usbshare smbd/trans2.c:2966: [2014/06/27 20:50:26.648113, all 3, pid=27664] smbd_do_qfsinfo smbd_do_qfsinfo: level = 1001 smbd/trans2.c:2966: [2014/06/27 20:50:26.648253, all 3, pid=27664] smbd_do_qfsinfo smbd_do_qfsinfo: level = 1005 smbd/trans2.c:2966: [2014/06/27 20:50:26.648639, all 3, pid=27664] smbd_do_qfsinfo smbd_do_qfsinfo: level = 1007 lib/sysquotas.c:470: [2014/06/27 20:50:26.649010, quota 3, pid=27664] sys_get_quota sys_get_vfs_quota() failed for mntpath[/volumeUSB2/usbshare] bdev[/dev/sdu1] qtype[2] id[0]: Function not implemented lib/sysquotas.c:470: [2014/06/27 20:50:26.649209, quota 3, pid=27664] sys_get_quota sys_get_vfs_quota() failed for mntpath[/volumeUSB2/usbshare] bdev[/dev/sdu1] qtype[4] id[100]: Function not implemented smbd/vfs.c:1131: [2014/06/27 20:50:26.665068, vfs 3, pid=27664] check_reduced_name check_reduced_name [1234567890ABCDEFG01.txt] [/volumeUSB2/usbshare] smbd/vfs.c:1265: [2014/06/27 20:50:26.665228, vfs 3, pid=27664] check_reduced_name check_reduced_name: 1234567890ABCDEFG01.txt reduced to /volumeUSB2/usbshare/1234567890ABCDEFG01.txt smbd/dosmode.c:335: [2014/06/27 20:50:26.665269, all 3, pid=27664] unix_mode unix_mode(1234567890ABCDEFG01.txt) returning 0777 smbd/open.c:810: [2014/06/27 20:50:26.666450, all 2, pid=27664] open_file admin opened file 1234567890ABCDEFG01.txt read=Yes write=Yes (numopen=3) smbd/oplock_linux.c:160: [2014/06/27 20:50:26.666582, locking 3, pid=27664] linux_set_kernel_oplock linux_set_kernel_oplock: got kernel oplock on file 1234567890ABCDEFG01.txt, file_id = 4141:5563:0 gen_id = 2260675554 smbd/dosmode.c:335: [2014/06/27 20:50:26.666626, all 3, pid=27664] unix_mode unix_mode(1234567890ABCDEFG01.txt) returning 0777 smbd/trans2.c:7802: [2014/06/27 20:50:26.667938, all 3, pid=27664] smbd_do_setfilepathinfo smbd_do_setfilepathinfo: 1234567890ABCDEFG01.txt (fnum 12406) info_level=1020 totdata=8 and then .. smbd/server.c:314: [2014/06/27 20:50:26.671574, all 3, pid=27454] remove_child_pid smbd/server.c:314 Unclean shutdown of pid 27664 smbd/server.c:322: [2014/06/27 20:50:26.671661, all 1, pid=27454] remove_child_pid Scheduled cleanup of brl and lock database after unclean shutdown smbd/server.c:275: [2014/06/27 20:50:46.693236, all 1, pid=27454] cleanup_timeout_fn Cleaning up brl and lock database after unclean shutdown I've checked permissions to the share and everything seems to be fine there (group users has read/write access). There are no issues when I first copy file to volume1 and then move it to usbshare2 - only with directly accessing the share from windows. Any ideas?