nile_c

I would suggest looking into the logs on the Smoothwall and filtering them via the IP address of the client machine at the time. This should indicate whether you're getting the expected authentication, and what filtering polices were in effect.

Another option is that the Superhub has stolen the IP of the smoothwall system. If you try browsing to the IP without specifying a port (e.g http://192.168.0.1/) you would see a Virgin branded settings page if the above is true.

I had confirmation from Youtube (overnight) that this was a temporary issue and is now resolved. Haven't tested it myself, but it appears you folks have!

I've had reports from elsewhere, but we're still trying to confirm and understand the cause.

If nearpod would like to get in touch, do let us know. Myself @OB1 @ibpalle or @tom_newton will be able to organise some sort of diagnosis tag-team

First port of call would be to check out 'Logs and reports » Logs » Web filter' on the Smoothwall web interface to locate any blocked requests. IIRC it would be a ggpht.com or an googleusercontent.com domain.

It's relatively straightforward to set up HTTPS inspection. However, you'll need to make considerations such as how the CA certificate will be distributed, what you'll do with byod devices, whether you'll be emailing users first, etc. You can view a short video here: 3 - Smoothwall - HTTPS Filtering - YouTube Also check out our knowledgebase accessed via the support portal. As @OB1 and @Oaktech have mentioned, you can block the sites.google.com domain in the meantime.

I can't speak for the official lightspeed advice, but I know of at least one Smoothie customer who is doing this successfully! Let me know if you run into any snags while testing.

It sounds to me like Google is transferring signed-in users onto an HTTPS connection. What's the situation with the LA filter and secure sites? If the issue is HTTPS, you could look into the NoSSLsearch option provided by Google. This causes Google search to revert to plain ol' HTTP connections. Obviously it's no help for the rest of the web :-)

For a Smoothwall user, yes it would. Within 'Web Proxy > Authentication > Exception' you could add the category 'SSL /CRL' which includes the relevant CRL and OCSP servers. ... in fact, that's part of the new (March '13) example policies for a new installation.

If it isn't obviously your web filter, try your firewall. In particular, the flash object might be using RTMP (port 1935) as a streaming transport.

Good morning folks! We're hiring again at Smoothwall. The role is as an Internet Analyst within the team that develops the Guardian blocklists. Full details are at - Internet Analyst. Please get in touch with me or @tom_newton if you need to know anything else.

Hi Kenny, sounds to me as through this is an issue with Ranged GET. The iOS Youtube app uses ranged gets requests, which your smoothie won't allow by default. You'll need to add a rule for the relevant location/group. Have a gander at this: http://www.edugeek.net/forums/smoothwall-direct-support/95393-youtube-broken-ios.html Cheers

That all sounds good. It is now mounted and available at /raid1 As you say, modern file managers will generally have handy links for Home and Root, etc. If you plug in a removable storage device, or insert a CD/DVD these also show up and you can mount/unmount them as a regular user. Dolphin isn't likely to show your raid array here, because it's already configured in your fstab and mounted. However you can navigate to /raid1 and use it as you would any other directory. The permissions might need to be made more permissive EDIT: What CAWJAmes said! I got distracted before I hit 'post' on mine

Hi tickmike, Good luck with your smoothie! As for the NAS... df is showing it's not currently mounted, and the 'mount: /dev/md0: can't read superblock' is telling us that it isn't formatted. So you'll need to go ahead and do that. As always with partitions and formatting, here be dragons. Now you have a partition on each disk (/dev/sdb1 and /dev/sdc1) which are "real" block devices. mdraid has built your RAID1 atop both of these, and now you've got the "virtual" block device /dev/md0. From here on we can forget about the real disks and refer to '/dev/md0'. The kernel will handle the RAID stuff behind the curtain. If we play with sdb or sdc the data gods will harm us. In the simplest case you can format with: mkfs -t xfs /dev/md0 Did you really want XFS? If not you'll need to change the -t parameter to reflect that.