SRX

Hey guys,

I'm getting the following error when trying to mount my usb key on the SRX240 in a cluster;

% ls /dev/da*
/dev/da0        /dev/da0s1c     /dev/da0s2c     /dev/da0s3e     /dev/da0s4a
/dev/da0s1      /dev/da0s2      /dev/da0s3      /dev/da0s3f     /dev/da0s4c
/dev/da0s1a     /dev/da0s2a     /dev/da0s3c     /dev/da0s4
% umass1: Integral Courier, rev 2.00/1.00, addr 4
da1 at umass-sim1 bus 1 target 0 lun 0
da1: <Integral Courier PMAP> Removable Direct Access SCSI-0 device
da1: 40.000MB/s transfers
da1: 7640MB (15646720 512 byte sectors: 255H 63S/T 973C)

% ls /dev/da*
/dev/da0        /dev/da0s2      /dev/da0s3c     /dev/da0s4a
/dev/da0s1      /dev/da0s2a     /dev/da0s3e     /dev/da0s4c
/dev/da0s1a     /dev/da0s2c     /dev/da0s3f     /dev/da1
/dev/da0s1c     /dev/da0s3      /dev/da0s4      /dev/da1s1
% mount_msdosfs /dev/da1s1 /mnt
mount_msdosfs: /dev/da1s1: Operation not permitted

Any ideas why this might be happening?

I only just formatted my usb key in windows to FAT32 and then copied the junos image onto it.

Thanks,

Paul

Hi,

Try the following:

mount -t msdosfs /dev/da1s1 /mnt

Hi there,

thanks for your reply. I tried your suggestion:

--- JUNOS 10.0R3.10 built 2010-04-16 08:47:35 UTC
{primary:node0}
pkilcoyne@f1-jrs1> start shell
% mount -t msdosfs /dev/da1s1 /mnt
mount_msdosfs: /dev/da1s1: Operation not permitted
%

Same issue 😞

Paul

Try using da0s1.  I sometimes come across a similar issue and I end up plugging in the stick why consoled in to confirm what to use.  

Hi Firewall,

thanks for the suggestion. Originally I plugged the USB key into USB-0 on the SRX240, it showed up as da1s1 in the shell, when I moved the USB key to USB-1 it still showed up as da1s1.

How can I select da0s1???

Thanks,

Paul

Try this: mount -t msdosfs /dev/da0s1 /mnt

If that doesn't work.  Have a look at the following:  http://kb.juniper.net/InfoCenter/index?page=content&id=KB16652&smlogin=true#cli_stick

Hi again,

I tried following that document previously.

Is it possible that my USB key is not compatible?

It is made by a company called "Integral"

Thanks,

Paul

Hi it is very possible. I had two of them that would not mount.
I purchased a Kingston and it worked fine

You need to be root, or a full superuser.

Edit:  Oh, and don't mess with da0, that's your internal compact flash device.  Bad juju.

OK,

I'm using a different USB key now and logged in as "root".

I can issue the command "mount -t msdosfs /dev/da0s1 /mnt" now no problem.

But when I try the command "mount -t msdosfs /dev/da1s1 /tmp/usb"

it says: "mount_msdosfs: /dev/da1s1: Operation not permitted"

Am I doing anything wrong?

How can I proceed?

Regards,

Paul

Guys,

I got it working!!!!

I used "da2s1"

Weird but it worked.

Thanks for all your help.

Paul

Guys,

now that I've all my JUNOS upgrades done, can I ask a few questions as to understanding the process?

1. When I do the "mount -t msdosfs /dev/da2s1 /tmp/usb" does this command copy the junos file to /tmp/usb on the SRX or does it merely link it to /tmp/usb ??

2. What does the command "request system software add /tmp/usb/<junos file name> no-validate no-copy" do exactly, does it copy from the usb key or from the file /tmp/usb to flash memory?

Just trying to understand the process here, once done so I won't have to remember anymore as I'll understand 🙂

Many thanks,

Paul

1- The mount command is a Unix/Linux command that causes the USB to be "mounted" via the /tmp/usb mount point. There is no file transfer occuring. That is simply how you instruct the OS to get to the USB to be able to move files to and from it. So, yes, it is a link.

2- Again, when you do the no-copy the install file is read from the USB key that is accessed via the mount you created.

One key thing about Junos is that all file operations, etc.... are really just Unix commands. Junos is based on the FreeBSD operating system and that is what is executing the underlying commands.

Kevin,

thanks for that reply.

On the "request system software add /tmp/usb/<junos> no-validate no-copy" command, what exactly happens when this command is entered?

Does it just point, to use a cisco term "bootvar",  to the usb key file and then when the command "request system reboot" is entered the device boots and loads from the firmware held on the usb key?

i.e. what if I removed the usb key between the two commands, would the srx fail to load the software?

Thanks,

Paul

Hey Paul - just saw your message  - The software is loaded at the time of the request command. You can remove the USB key prior to the reboot as the software is already installed on the unit. Hope that answers your question.

Hi Kevin,

thanks for that.

Regards,

Paul

Guys,

I've just noticed that I cannot run the command "mount -t msdosfs /dev/da1s1 /tmp/usb" when in superuser mode, it comes back with the error:

root@%  -t msdosfs /dev/da1s1 /tmp/usb
root@% sdosfs: /dev/da1s1: Operation not permitted

But I can run it while logged in as "root".

Is this normal?

Thanks,

Paul

Paul - that is interesting and something I never tried. But you are 100% correct. I did also do an "su" while logged in as a non root superuser and then the command worked. On the surface I would think this would be a bug.

Hey,

thanks for the reply. It does seem odd.

I'm upgradingnew SRX240H's out of the box to the recommended JUNOS version as of 18th of August 2011. I'm just worried if we have to upgrade SRX's that are in production and we can't remember our root password.

Should this be brought to the attention of the developers?

Paul

If you have the time it might be a good idea to open up a JTAC case and get the word from them on why.

OK will do,

Thanks,

Paul

To borrow a phrase from Microsoft's documentation practices, I would say that "this is behavior as designed."

The disk device files in /dev are owned by root, group ownership to the operator group, with 640 permissions (rw-r-----).  That means that root, and ONLY root, has access write to the device node, and members of the "operator" group can read from it.  The "mount" command is not a setuid binary, therefore it cannot perform root-level actions on its own, so the invoking user must be root so that the "mount" command can read/write to/from the device node.  Otherwise, a member of the "operator" group can also mount the device, but they must specify that it be mounted read-only.

% ls -l /dev/da*
crw-r-----  1 root  operator    0,  47 Oct  6 02:49 /dev/da0
crw-r-----  1 root  operator    0,  48 Oct  6 02:49 /dev/da0s1
crw-r-----  1 root  operator    0,  52 Oct  6 02:49 /dev/da0s1a
crw-r-----  1 root  operator    0,  53 Oct  6 02:49 /dev/da0s1c
crw-r-----  1 root  operator    0,  49 Oct  6 02:49 /dev/da0s2
crw-r-----  1 root  operator    0,  54 Oct  6 02:49 /dev/da0s2a
crw-r-----  1 root  operator    0,  55 Oct  6 02:49 /dev/da0s2c
crw-r-----  1 root  operator    0,  50 Oct  6 02:49 /dev/da0s3
crw-r-----  1 root  operator    0,  56 Oct  6 02:49 /dev/da0s3c
crw-r-----  1 root  operator    0,  57 Oct  6 02:49 /dev/da0s3e
crw-r-----  1 root  operator    0,  58 Oct  6 02:49 /dev/da0s3f
crw-r-----  1 root  operator    0,  51 Oct  6 02:49 /dev/da0s4
crw-r-----  1 root  operator    0,  59 Oct  6 02:49 /dev/da0s4a
crw-r-----  1 root  operator    0,  60 Oct  6 02:49 /dev/da0s4c
crw-r-----  1 root  operator    0,  81 Oct  6 02:49 /dev/da1
crw-r-----  1 root  operator    0,  82 Oct  6 02:49 /dev/da1s1

Accounts created as "superuser" accounts in Junos do not get added to the "operator" Unix system group.

I have a "keithr" superuser account on a brand new SRX240 I just set up...  if I "start shell" from my account, I am dropped into the shell as my user, as I would expect:

keithr@test-srx240> start shell
% whoami
keithr
%

Here, I can see what groups I belong to:

% id
uid=2000(keithr) gid=20(staff) groups=20(staff), 0(wheel), 10(field), 11(floppy)
%

I am UID 2000, primary group is GID 20 (group name "staff").  I also belong to groups 0 (wheel), 10 (field), and 11 (floppy).  For the non-old-and-bearded among us, "wheel" is the "rootiest" of groups in BSD-derived systems.  However, even members of wheel can't override permissions.  As my keithr superuser account is not a member of the operator group, and obiously it's not the root account, I can't mount a /dev/da* device as keithr.

% mount -t msdosfs /dev/da1s1 /tmp/usb
mount_msdosfs: /dev/da1s1: Operation not permitted

I need to become "root".

% su -
Password:

root@test-srx240% whoami
root

root@test-srx240% id
uid=0(root) gid=0(wheel) groups=0(wheel), 5(operator), 10(field), 11(floppy), 31(guest), 73(config)

root@test-srx240%
root@test-srx240%
root@test-srx240% mount -t msdosfs /dev/da1s1 /tmp/usb

root@test-srx240% ls /tmp/usb
.Spotlight-V100                         ._junos-srxsme-10.4R7.5-domestic.tgz
.Trashes                                junos-srxsme-10.4R7.5-domestic.tgz
._.Trashes
root@test-srx240%

As root, it let me mount the USB device and I can list its contents.  The files that start with the dots are because I copied the junos image using my Mac, and the Mac does that goofy stuff for its internal catalog and Spotlight cache.

Great explaination!

root@AbedFirewall% whoami
root
root@AbedFirewall% ls -l /dev/da*
crw-r----- 1 root operator 0, 46 Aug 8 22:04 /dev/da0
crw-r----- 1 root operator 0, 47 Aug 8 22:04 /dev/da0s1
crw-r----- 1 root operator 0, 95 Aug 8 22:04 /dev/da0s1a
crw-r----- 1 root operator 0, 96 Aug 8 22:04 /dev/da0s1c
crw-r----- 1 root operator 0, 48 Aug 8 22:04 /dev/da0s2
crw-r----- 1 root operator 0, 53 Aug 8 22:04 /dev/da0s2a
crw-r----- 1 root operator 0, 54 Aug 8 22:04 /dev/da0s2c
crw-r----- 1 root operator 0, 49 Aug 8 22:04 /dev/da0s3
crw-r----- 1 root operator 0, 55 Aug 8 22:04 /dev/da0s3c
crw-r----- 1 root operator 0, 56 Aug 8 22:05 /dev/da0s3e
crw-r----- 1 root operator 0, 57 Aug 8 22:05 /dev/da0s3f
crw-r----- 1 root operator 0, 50 Aug 8 22:04 /dev/da0s4
crw-r----- 1 root operator 0, 58 Aug 8 22:04 /dev/da0s4a
crw-r----- 1 root operator 0, 59 Aug 8 22:04 /dev/da0s4c
crw-r----- 1 root operator 0, 60 Aug 8 22:04 /dev/da0s4e
crw-r----- 1 root operator 0, 91 Aug 8 22:04 /dev/da1
crw-r----- 1 root operator 0, 92 Aug 8 22:04 /dev/da1s1
root@AbedFirewall% mount -t msdosfs /dev/da1 /var/tmp/usb/
mount_msdosfs: /dev/da1: Invalid argument
root@AbedFirewall% mount -t msdosfs /dev/da1d1 /var/tmp/usb/
mount_msdosfs: /dev/da1d1: No such file or directory
root@AbedFirewall% mount -t msdosfs /dev/da1s1 /var/tmp/usb/
mount_msdosfs: /dev/da1s1: Invalid argument
root@AbedFirewall% mount -t msdosfs /dev/da0s1 /var/tmp/usb/
mount_msdosfs: /dev/da0s1: Invalid argument
root@AbedFirewall% mount -t msdosfs /dev/da1 /var/tmp/usb/
mount_msdosfs: /dev/da1: Invalid argument
root@AbedFirewall% mount -t msdosfs /dev/da1s1 /var/tmp/usb/
mount_msdosfs: /dev/da1s1: Invalid argument
root@AbedFirewall%

not working !

Not working for me. I'm root and still get operation not permitted. 

Hi Folks,
Please find the below KB article on the same,

https://kb.juniper.net/InfoCenter/index?page=content&id=KB12880&actp=METADATA

I am still getting the same error

root> show log messages | match da
Jan 24 02:18:15   /kernel: da1 at umass-sim1 bus 1 target 0 lun 0
Jan 24 02:18:15   /kernel: da1: <General UDisk 5.00> Removable Direct Access SCSI-2 device
Jan 24 02:18:15   /kernel: da1: 40.000MB/s transfers
Jan 24 02:18:15   /kernel: da1: 15000MB (30720000 512 byte sectors: 255H 63S/T 1912C)

root@:RE:0% ls -l /dev/da*
crw-r-----  1 root  operator    0,  54 Feb  7 23:59 /dev/da0
crw-r-----  1 root  operator    0,  56 Feb  7 23:59 /dev/da0s1
crw-r-----  1 root  operator    0,  64 Feb  7 23:59 /dev/da0s1a
crw-r-----  1 root  operator    0,  65 Feb  7 23:59 /dev/da0s1c
crw-r-----  1 root  operator    0,  57 Feb  7 23:59 /dev/da0s2
crw-r-----  1 root  operator    0,  66 Feb  7 23:59 /dev/da0s2a
crw-r-----  1 root  operator    0,  67 Feb  7 23:59 /dev/da0s2c
crw-r-----  1 root  operator    0,  58 Feb  7 23:59 /dev/da0s3
crw-r-----  1 root  operator    0,  68 Feb  7 23:59 /dev/da0s3c
crw-r-----  1 root  operator    0,  69 Feb  7 23:59 /dev/da0s3d
crw-r-----  1 root  operator    0,  70 Feb  7 23:59 /dev/da0s3e
crw-r-----  1 root  operator    0,  59 Feb  7 23:59 /dev/da0s4
crw-r-----  1 root  operator    0,  71 Feb  7 23:59 /dev/da0s4c
crw-r-----  1 root  operator    0,  72 Feb  7 23:59 /dev/da0s4d
crw-r-----  1 root  operator    0,  55 Feb  7 23:59 /dev/da1
crw-r-----  1 root  operator    0,  60 Feb  7 23:59 /dev/da1s1
crw-r-----  1 root  operator    0, 126 Feb  7 23:59 /dev/da1s1a
crw-r-----  1 root  operator    0, 127 Feb  7 23:59 /dev/da1s1c
crw-r-----  1 root  operator    0,  61 Feb  7 23:59 /dev/da1s2
crw-r-----  1 root  operator    0,  75 Feb  7 23:59 /dev/da1s2a
crw-r-----  1 root  operator    0,  76 Feb  7 23:59 /dev/da1s2c
crw-r-----  1 root  operator    0,  62 Feb  7 23:59 /dev/da1s3
crw-r-----  1 root  operator    0,  77 Feb  7 23:59 /dev/da1s3c
crw-r-----  1 root  operator    0,  78 Feb  7 23:59 /dev/da1s3d
crw-r-----  1 root  operator    0,  79 Feb  7 23:59 /dev/da1s3e
crw-r-----  1 root  operator    0,  63 Feb  7 23:59 /dev/da1s4
crw-r-----  1 root  operator    0, 128 Feb  7 23:59 /dev/da1s4c
crw-r-----  1 root  operator    0, 129 Feb  7 23:59 /dev/da1s4d
root@:RE:0%

root@:RE:0% mkdir /var/tmp/usb

root@:RE:0% mount -t msdos /dev/da1s1 /var/tmp/usb
mount_msdosfs: /dev/da1s1: Invalid argument
root@:RE:0% mount -t msdos /dev/da1 /var/tmp/usb
mount_msdosfs: /dev/da1: Invalid argument
root@:RE:0%

root@:RE:0% ls -l /dev/
total 1
crw-------  1 root  wheel       0, 125 Feb  7 23:59 ack1713
lrwxr-xr-x  1 root  wheel            6 Feb  8 00:00 altroot -> da0s1a
crw-------  1 root  wheel       0,  41 Feb  7 23:59 bcm5664x.0
crw-------  1 root  wheel       0,  26 Feb  8 00:01 cfi0
crwx------  1 root  wheel       0,  17 Feb  8 00:00 console
crw-rw-rw-  1 root  wheel       0,  18 Feb  7 23:59 ctty
crw-rw----  1 uucp  dialer      0,  32 Feb  7 23:59 cuau0
crw-rw----  1 uucp  dialer      0,  33 Feb  7 23:59 cuau0.init
crw-rw----  1 uucp  dialer      0,  34 Feb  7 23:59 cuau0.lock
crw-rw----  1 uucp  dialer      0,  38 Feb  7 23:59 cuau1
crw-rw----  1 uucp  dialer      0,  39 Feb  7 23:59 cuau1.init
crw-rw----  1 uucp  dialer      0,  40 Feb  7 23:59 cuau1.lock
crw-r-----  1 root  operator    0,  54 Feb  7 23:59 da0
crw-r-----  1 root  operator    0,  56 Feb  7 23:59 da0s1
crw-r-----  1 root  operator    0,  64 Feb  7 23:59 da0s1a
crw-r-----  1 root  operator    0,  65 Feb  7 23:59 da0s1c
crw-r-----  1 root  operator    0,  57 Feb  7 23:59 da0s2
c