Zalman VE400 Review

Posted on by
3

I thought I’d post about the Zalman VE400 I’ve been using for a while now. The basic idea is that it’s a USB disk enclosure for a 2.5″ drive, but with a twist—it has a small LCD and keypad on the front, allowing you to create a directory of .iso files and pick one to export as a virtual CD/DVD. (It also supports some sort of hardware encryption, which I haven’t tried.)

Zalman ZE400 (behind Dell C6100)

I bought mine, along with a 120GB SSD. Installing the drive is quite easy. Just remove a couple screws on the enclosure, slide the disk into place (it’s literally that easy), and put it back together.

Rather than an extended narrative, I’ll do bullet points for the pros and cons.

Pros

  • The virtual ISO feature. I bought it just for this. I use it all the time. It saves me from burning a ton of DVDs. I can plug it into a system, select an ISO file on the screen, and have the machine see a USB CD/DVD drive appear with that. And, since it’s on an SSD and connected via USB 3, it feels much faster than a normal CD/DVD would.
  • You can use it as a normal hard drive, too. The ISOs go into a folder named _iso, and the rest is yours to use. You can select to present the thing as a CD/DVD-only, hard drive only, or both. (In which case it shows up as two devices.)

Cons

Where to start…

  • The thing requires that it be formatted as NTFS to work. (They do have some firmware available that might allow the use of FAT instead, but it certainly doesn’t ship that way.) I have a Mac and several Linux machines, neither of which have native NTFS support. (For the record, getting NTFS write working on Linux is significantly easier than on a Mac.)
  • The thing is fairly intolerant of filesystem fragmentation. I thought NTFS was supposed to somewhat reduce the impact of fragmentation. And I have an SSD inside, which doesn’t exactly require fragmentation, since seeks are practically free. But after filling this thing 2/3 of the way, I started getting an error, “>> DEFRAG <<“, whenever I tried to mount the latest ISO file. There is no documentation that seems to cover this, but it was clear what I had to do—defragment my solid-state drive, running NTFS, through Linux. (The “solution” to this, BTW, is to copy everything off of the drive, reformat it as a new NTFS filesystem, and copy everything back.) It was just incapable of reading the fragmented ISO.
  • The keypad. Why, oh why, did they think having it be a flat piece of plastic was a good idea? It looks ugly, and it works poorly. The NewEgg reviews are full of complaints about the keypad not working. Mine works, but there’s zero tactile feedback, so you have to watch and see if the key registers. It’s just a horrible idea.
  • There’s practically no documentation. Requires NTFS? Needs defragmentation? I got to figure those things out on my own or from others on the Internet.
  • Firmware updates require Windows to install, so I have no means of applying them.

Zalman ZE400 showing selected ISO

Summary

I gave this a 3-star rating on NewEgg, where the average rating is a 2-star review. My opinion has not improved.

However, I would buy this again if I lost it. Despite its many flaws and quirks, I’m yet to find anything else that offers the same functionality.

Fixing X11 forwarding request failed on channel 0

Posted on by
Reply

I see this error a lot:

mawagner ~ $ ssh root@mawagner-cs24.usersys.redhat.com
root@mawagner-cs24.usersys.redhat.com's password:
X11 forwarding request failed on channel 0

There are a lot of forum posts about people having this problem, but surprisingly few questions that give a good answer. It just took me forever to run down what was causing it for me.

This gist is the closest I’ve seen to a big-picture look at what’s going on, but it still didn’t directly solve my problem. My solution came here (French). But the short version is this: that error can be caused by a lot of things.

Here’s a list of things I would check, in order of ease:

  1. ssh’ed into the remote machine, is an “xauth” command available for you to run? You don’t even have to run it, but does it exist? This was my problem, and it was fixed with yum install xorg-x11-xauth (or the equivalent for non-yum systems).
  2. Pop open /etc/ssh/sshd_config. Make sure that the X11Forwarding line is set to “yes”. Otherwise, X forwarding will absolutely not work. (You may wish to read the sshd_config manpage, as there are some security implications to enabling this—though if you’re reading this, you obviously want to use this feature.)
  3. Others have reported needing to change X11UseLocalhost to no, but I haven’t found this to be necessary. The man page suggests that this is only needed for “some older X11 clients”. Most of the posts I’ve seen about this setting seem to involve people changing settings randomly hoping to hit on a working solution, so don’t change this or X11DisplayOffset unless nothing else works.

Remember that after changing sshd_config, you must service restart sshd. This should not impact existing sessions. (But I always open a new tab in my terminal and test login there before logging out of the existing session, to make sure sshd came up cleanly so I don’t accidentally lock myself out.)

Another recommendation (which I totally missed until I had solved the issue) was to add the -v flag when starting your ssh session, to enable verbose logging. This might indicate the problem.

If none of the above solves your problem, this page (also linked above) was very helpful. Hopefully this post will help someone, though. (Please note that I am by no means an expert on getting X11 forwarding working with X. I just happen to have fixed it in my case and wanted to write up what I did, for my future self or for others.)

One Weird Trick to Make NFS Work

Posted on by
2

I am by no means an expert on NFS. I border on being NFS-literate, in fact. But I excel at encountering errors. Here, I will attempt to document some of the ones I’ve figured out how to fix / work around.

mount.nfs: access denied by server

This is the error that led to the joking “one weird trick” (referencing those spammy ads) title of this post.

I keep running into errors like this:
$ sudo mount -t nfs winterfell:/home/j /mnt/j
mount.nfs: access denied by server while mounting winterfell:/home/j

I think the error can be caused by a number of things. From the client, check that showmount -e winterfell (where winterfell, of course, is the name of the server you’re trying to mount a volume from) (a) returns anything at all (meaning you can at least reach the server), (b) lists the share matching the one you’re trying to mount, and (c) has an IP mask that matches the one you’re connecting from.

If (a) fails, check iptables (make sure port 2049, at least, is open). If (b) or (c) fails, fix it in /etc/exports, and reload the config with exportfs -r.

But if everything above looks normal, but you can’t actually mount the share, it’s probably this: NFSv4 appears to require functional reverse DNS or it will fail without telling you much about what’s going on. I’m still a bit in the dark on the details. You might try using the IP instead of a hostname. If that doesn’t work, the “one weird trick” is to fall back to NFSv3 (or even NFSv2, but don’t), which doesn’t do this. Something like this:

sudo mount -t nfs -o nfsvers=3 winterfell:/home/j /mnt/j

If that succeeds, you’ll know the problem.

mount_nfs: can’t mount $share from $hostname onto $mountpoint: Operation not permitted

I keep getting this one when trying to mount things on a Mac client.

This is fixed by adding the -o resvport flag to your mount command, e.g.:

sudo mount -t nfs -o resvport winterfell:/home/j /mnt/j

IIUC, what is happening here is that the server is requiring that clients connect from a reserved (<1024) port (which only superusers can do), but the Mac client doesn’t do that by default. -o resvport tells it to bind to a reserved port, and you’re golden.

Hopefully someone else will find these tips useful. (That “someone else” may be me in six months’ time…)