7 answers

Thanks for that. You're right in that I was using steps from SAIO for virtual devices. Turning mount_check=false has seemed to have fixed things.

The thing is, I actually am mounting a separate device (hard drive) whose path I am specifying (/dev/sdb1 is mounted at /mnt/sdb1). However when I had mount_check=true and devices=/dev/sdb1 the services were telling me the device was not mounted. Why was that?

Ah, devices= is supposed to be set to the directory where a set of mount points can be found. The system is set up to allow many drives per server. For instance, we often have systems with devices=/srv/node and if you did an ls /srv/node you might see:

I'm pretty sure you don't want devices=/dev/sdb1 but you probably don't want devices=/mnt either. By convention, you might want to create an /srv/node directory and mount sdb1 at /srv/node/sdb1 and set devices=/srv/node

With devices=/dev/sdb1 I'm not sure what might be happening on your system. It might actually be trying to write files to /dev/sdb1/sdb1/* If you're running as root, it might actually be succeeding! Best to double check things aren't wonky in that respect; you may need to do a bit of cleanup.

Ah, the 507 returned by the account server in there indicates the account server thinks the device is not mounted.

If you're using "pretend" devices as with the standard SAIO, you'll want to ensure mount_check = false is in your account-server.conf file (or your account-server/*.conf files) under the [DEFAULT] section(s).

If that's not set right in your account server configurations, you'll want to double check your container and object server configurations too.

Thanks for setting me straight on this. This has definitely helped me go groom all my config files. I'm going to post one more problem at the expense of looking like a total noob, but the 503 error has re-spawn in a different form. The syslog now returns:

Ah, okay. That error is now the proxy server trying to connect back to the auth server for token validation. If you're auth server is configured to run on port 80, you'll need to set port=80 in your proxy-server.conf under the [filter:auth] section. It defaults to 11000, which I think is what the auth server defaults to.

This has gotten me past the 503 error (thanks) but has created another one. Now when issuing the same command (swift-auth-add-user -K cumulo -a test tester testing) the terminal hangs and I'm forced after a minute or so to interrupt (command-c) it. The terminal spits out a traceback:

When adding a new account/user, the auth server will call out to the proxy server based on the default_cluster_url config file value (defaults to http://127.0.0.1:8080/v1 I think). Might double-check that value in /etc/swift/auth-server.conf and that you're running the proxy server on that same port (bind_port value, I think that defaults to port 80).