Destination Folder Access Denied

Thanks. The OP is going to be busy; did you see the strangely long list of things reported to be mounted on sda4? All those files? That doesn’t look right to me, compared to my list, which looks a lot more sensible.

1 Like

As long as nothing is in use on those mounts, you should be able to hit them all at once with a

umount /dev/sda4 --force

That will force unmount the block device. Since it is mounted RO, there shouldnt be anything other than whiny processes complaining about not being able to access whatever they were accessing. He should be able to do the fsck then.

2 Likes

Good point…

I had found the force option, but that sounded a bit scary. But, as you say, it’s mounted RO, so won’t cause a problem by forcibly unmounting.

1 Like

Thank you for your replies.
Before I pull the trigger on this, does this look right ?

killall nfsd*
killall smbd*
umount /dev/sda4 --force
e2fsck /dev/sda4

pretty much. when the e2fsck finishes, tell it to reboot.

1 Like

I put in the first line, killall nfsd* but it looks like it does not recognize it. says nfsd* : no process found. is that correct? Or does that just mean NFS is not running?
killall smbd* says no process also.

Just for laughs and giggles, I ran the other lines but didnt seem to work.

Until the /dev/sda4 is unmounted. You can’t do a e2fsck.

1 Like

Thank you rac, that makes sense. One question, in your post above umount /nsf/Username, is that the actual word Username, or is it the username of a share? I will try your suggestions.

Sorry should have been Username. When you look at the mount output. Use the data that is between on and type for each /dev/sda4 entry.
If it won’t umount because it is busy. You can run the following command
lsof |grep sda4
this will show you each process that is using /dev/sda4. Then you can kill the process that has it in use. The process number is in the second column. So type
kill number

1 Like

The user name of the share. I redacted my name from my list of mounts, replacing it with ‘Username’. rac replied to my comment.

1 Like

This was the output he provided. Note the /nfs/Username

1 Like

I tried the first umount, [umount /DataVolume] but it said ‘busy’ so I used the command : lsof |grep sda4 and it showed me 3 things with the same # (in second row: 5251).
I tried to ‘kill 5251’ it but it didnt seem to work.

should I do a kill -15 5251

?

You could try it.

1 Like

in this case, i would use

kill -9 5251

If we STILL can’t get it to let go, I would then resort to temporary modification of /etc/fstab to prevent it ever mounting at all on boot, then doing the needful, and afterwards rescinding the changes so it mounts normally again.

1 Like

I tried the -15 and the -9. neither took away the ‘busy’ problem. I tried the killall for Samba and NSF again for laughs and giggles, but that didnt seem to work.

Found this forum about kill problems.
Did a ps -Al and didnt see any Z’s (for zombie)

I did a reboot and now the (3) busy PID’s are 5240 instead of the previous 5251. Appears to be same items just with the 5240 PID now.
Going on the possibility of a parent process being in place, I tried to ‘kill -9 2’ after locating the 5240 PID in ‘ps -Al’, but again, killing the parent [2] if I am correct in my assumption, did not let me kill -9 the 5240.

Strange thing :confused:

Can’t do the fstab method. The mounted disks are not in the fstab. The data disks get mounted with a /etc/rc1.d/S15mountDataVolume.sh script.

1 Like