sdh's dashboard

Good point, Jeff. Thinking about it, I guess that effectively building in an iSCSI initiator, which was what I was suggesting, would take Expandrive away from its core functionality of managing the drive connections themselves as simply as possible, and could make things unnecessarily complicated for the large majority of its users. (And its developers, too, of course).

Steve

Hi Jeff

On my Qnap NAS, the latest version of Expandrive (1.3) now reports the correct free space (exactly the same as if I connect to it with SMB, for example). I'm now sure the problem was caused by the deliberately crippled ssh daemon that Qnap saw fit to install as the default. I used ipkg, which Qnap support, to install a new set of openssl libraries and sftp-server. Connecting to the NAS using this version of the ssh daemon Expandrive works perfectly.

Steve

Matt

Thanks for the reply. I've done a little more investigation, and I can see where the reported free space values are coming from for the different users, though I have no idea why they should be different.

The NAS is a QNAP TS-109. It has an embedded Linux system, but it is configured in such a way that Linux is somewhat incidental. The QNAP supplied sshd, for example, is crippled so that it will only allow the admin user to log in. It also stores a lot of its default configuration in flash and loads the system into RAM on rebooting, thus overwriting any changes one makes to the standard configuration. A recent QNAP firmware upgrade brought in support for Optware ipkg, thus allowing more permanent enhancements to the system to be made. I've used ipkg to install openssh and sftp-server.

Looking at the output of the df command, it appears that the free space as reported for a standard user is the free space on the largest, data partition (/dev/sda3) and is correct. currently 423.7G. Using Expandrive to connect as admin, though, (again to the optware ssh daemon, which has a default configuration) the free space is reported as only 2.8M, which is the free space on a different device (/dev/ram0). Expandrive also behaves like it should if there was only 2.8M free - a 3M file cannot be copied.

If I connect to the QNAP sshd as admin, which is the only user allowed to connect to this daemon, this is when I get 8TB of free space reported.

I'm happy to work with you to debug this on the optware ssh daemon. I could grant you access direct to my NAS box, and I'm happy to run any debugging scripts or try different builds of Expandrive. I don't think that it is worth pursuing the QNAP ssh daemon any more, though, on account that it is not a standard build of sshd.

Thanks for the explanation. I'm not sure how the .DS_Store file arose - the folder I'm accessing was one I created a long time ago and have only just rediscovered. Thinking back it was probably mounted over AFP.

I think I'll manage with it as is for now. The work around - to delete the file manually over a standard SSH connection isn't too onerous. It could probably do with an entry in an FAQ or the program help files though. Thanks for an excellent little utility.

Both commands produced exactly the same output:

(1024, 1024, 9911L, 2855L, 2855L, 2560L, 1498L, 1498L, 0, 255)

Some updates for you.

(Matt) Yes, df does work on my NAS.
(Jon) It doesn't have Python installed by default, but through the wonders of ipkg it does now. However the free space is still reported as 8TB. Could there be a module that I'm missing? I have installed the default python-2.5 package (actually version 2.5.2).

Ok, thanks for the reply. The NAS does have ssh access - I use it all the time to manage it. What would you like to know about it?